#hausautomation — Public Fediverse posts on home.social

Crazy-to-Bike @[email protected] · 2026-08-08 · 08:02 UTC

Ich habe bei #Homeasistant schon seit langem den unschönen Effekt, dass bei Neuladen der Konfiguration, z.B. nach Änderungen an der configuration.yaml, #Ausreißer entstehen. Dies betrifft ausschließlich #Entitäten, die ich in der configuration.yaml angelegt habe, immer die Gleichen, aber bei Weitem nicht alle.

Leider ergibt sich da immer ein Rattenschwanz, da ich #HA sehr stark für das Erfassen von Werten und Statistiken nutze (deshalb auch aus meiner Calc-Tabelle für die Hausverbäuche etc. historische Daten von der Zeit vor HA importiert habe) und diverse Berechnungen aus anderen Entitäten machen lasse. Wenn eine daran beteiligte Entität einen Ausreißer produziert, haben logischerweise alle daraus berechneten Entitäten ebenfalls Ausreißer. Da das bis vor 2 Versionen von HA wie gesagt immer nur beim Neuladen der Config auftrat, konnte ich gut damit leben.
Seit vorletzer Version von HA produziert es diese Ausweißer aber regelmäßig und nachvollziehbar immer zu denselben Zeitzpunkten: 0 Uhr, 6 Uhr, 12 Uhr, 18 Uhr 🤷‍♂️

Sieht für mich irgendwie nach Bug aus, da ich keine neuen oder geänderten Entitäten angelegt habe 🤔

Ein Beispiel für eine immer betroffene (mein Verdacht, eine der auslösenden) Entität:

- sensor:
      - name: Gesamtertrag PV alt (mit Langzeitkorrektur)
        unique_id: gesamtertrag_pv_alt
        device_class: Energy
        state_class: total_increasing
        unit_of_measurement: "kWh"
        state: "{{ states('sensor.bitshake_smartmeterreader_ertrag_pv_alt') | float(2)  + 56120.32 | float(2) }}"

Ich habe dann versucht, die Ausreißer abzufangen, indem ich das State Argument so verändert habe:

state: >
  {% set new_value = states('sensor.bitshake_smartmeterreader_ertrag_pv_alt') | float(2)  + 56120.32 | float(2) %}
  {% set old_value = states('sensor.gesamtertrag_pv_alt') | float(2) %}
  {# Neuer Wert wird ignoriert, wenn die Werte gleich sind oder weil er nicht kleiner sein kann als alter Wert #}
  {% if new_value <= old_value %}
    {{ old_value }}
  {# Wenn mehr als 0,5 kWh hinzugekommen -> wird als Ausreißer betrachtet und alter Wert genommen #}
  {% elif new_value - old_value > 0.5 %}
    {{ old_value }}
  {# Normale Werte #}
  {% else %}
    {{ new_value }}
  {% endif %}

Im ersten Moment schien das zu funktionieren, aber dann hat's den Gesamtertrag, also den Zählerstand genullt, obwohl die Zahlen das nicht hergaben.

sensor.bitshake_smartmeterreader_ertrag_pv_alt hatte 6827,28, macht mit der Addiion von den historischen 56120,32 62947,6 für new_value .
Der Zählerstand vor der Nullung, also old_value, war ebenfalls 62947,6.

Also hätte imho doch {% if new_value <= old_value %}{{ old_value }} greifen müssen, und das wäre eben weiterhin 62947,6 gewesen 🤷‍♂️

Warum funktioniert das nicht? Warum nullt es mir den Zählerstand? 🤷‍♂️

#Hausautomation #Homeserver

#homeasistant #ausreißer #entitaten #ha #hausautomation #homeserver

Crazy-to-Bike @[email protected] · 2026-08-08 · 08:02 UTC

Ich habe bei #Homeasistant schon seit langem den unschönen Effekt, dass bei Neuladen der Konfiguration, z.B. nach Änderungen an der configuration.yaml, #Ausreißer entstehen. Dies betrifft ausschließlich #Entitäten, die ich in der configuration.yaml angelegt habe, immer die Gleichen, aber bei Weitem nicht alle.

Leider ergibt sich da immer ein Rattenschwanz, da ich #HA sehr stark für das Erfassen von Werten und Statistiken nutze (deshalb auch aus meiner Calc-Tabelle für die Hausverbäuche etc. historische Daten von der Zeit vor HA importiert habe) und diverse Berechnungen aus anderen Entitäten machen lasse. Wenn eine daran beteiligte Entität einen Ausreißer produziert, haben logischerweise alle daraus berechneten Entitäten ebenfalls Ausreißer. Da das bis vor 2 Versionen von HA wie gesagt immer nur beim Neuladen der Config auftrat, konnte ich gut damit leben.
Seit vorletzer Version von HA produziert es diese Ausweißer aber regelmäßig und nachvollziehbar immer zu denselben Zeitzpunkten: 0 Uhr, 6 Uhr, 12 Uhr, 18 Uhr 🤷‍♂️

Sieht für mich irgendwie nach Bug aus, da ich keine neuen oder geänderten Entitäten angelegt habe 🤔

Ein Beispiel für eine immer betroffene (mein Verdacht, eine der auslösenden) Entität:

- sensor:
      - name: Gesamtertrag PV alt (mit Langzeitkorrektur)
        unique_id: gesamtertrag_pv_alt
        device_class: Energy
        state_class: total_increasing
        unit_of_measurement: "kWh"
        state: "{{ states('sensor.bitshake_smartmeterreader_ertrag_pv_alt') | float(2)  + 56120.32 | float(2) }}"

Ich habe dann versucht, die Ausreißer abzufangen, indem ich das State Argument so verändert habe:

state: >
  {% set new_value = states('sensor.bitshake_smartmeterreader_ertrag_pv_alt') | float(2)  + 56120.32 | float(2) %}
  {% set old_value = states('sensor.gesamtertrag_pv_alt') | float(2) %}
  {# Neuer Wert wird ignoriert, wenn die Werte gleich sind oder weil er nicht kleiner sein kann als alter Wert #}
  {% if new_value <= old_value %}
    {{ old_value }}
  {# Wenn mehr als 0,5 kWh hinzugekommen -> wird als Ausreißer betrachtet und alter Wert genommen #}
  {% elif new_value - old_value > 0.5 %}
    {{ old_value }}
  {# Normale Werte #}
  {% else %}
    {{ new_value }}
  {% endif %}

Im ersten Moment schien das zu funktionieren, aber dann hat's den Gesamtertrag, also den Zählerstand genullt, obwohl die Zahlen das nicht hergaben.

sensor.bitshake_smartmeterreader_ertrag_pv_alt hatte 6827,28, macht mit der Addiion von den historischen 56120,32 62947,6 für new_value .
Der Zählerstand vor der Nullung, also old_value, war ebenfalls 62947,6.

Also hätte imho doch {% if new_value <= old_value %}{{ old_value }} greifen müssen, und das wäre eben weiterhin 62947,6 gewesen 🤷‍♂️

Warum funktioniert das nicht? Warum nullt es mir den Zählerstand? 🤷‍♂️

#Hausautomation #Homeserver

#homeasistant #ausreißer #entitaten #ha #hausautomation #homeserver

Crazy-to-Bike @[email protected] · 2026-08-08 · 08:02 UTC

Ich habe bei #Homeasistant schon seit langem den unschönen Effekt, dass bei Neuladen der Konfiguration, z.B. nach Änderungen an der configuration.yaml, #Ausreißer entstehen. Dies betrifft ausschließlich #Entitäten, die ich in der configuration.yaml angelegt habe, immer die Gleichen, aber bei Weitem nicht alle.

Leider ergibt sich da immer ein Rattenschwanz, da ich #HA sehr stark für das Erfassen von Werten und Statistiken nutze (deshalb auch aus meiner Calc-Tabelle für die Hausverbäuche etc. historische Daten von der Zeit vor HA importiert habe) und diverse Berechnungen aus anderen Entitäten machen lasse. Wenn eine daran beteiligte Entität einen Ausreißer produziert, haben logischerweise alle daraus berechneten Entitäten ebenfalls Ausreißer. Da das bis vor 2 Versionen von HA wie gesagt immer nur beim Neuladen der Config auftrat, konnte ich gut damit leben.
Seit vorletzer Version von HA produziert es diese Ausweißer aber regelmäßig und nachvollziehbar immer zu denselben Zeitzpunkten: 0 Uhr, 6 Uhr, 12 Uhr, 18 Uhr 🤷‍♂️

Sieht für mich irgendwie nach Bug aus, da ich keine neuen oder geänderten Entitäten angelegt habe 🤔

Ein Beispiel für eine immer betroffene (mein Verdacht, eine der auslösenden) Entität:

- sensor:
      - name: Gesamtertrag PV alt (mit Langzeitkorrektur)
        unique_id: gesamtertrag_pv_alt
        device_class: Energy
        state_class: total_increasing
        unit_of_measurement: "kWh"
        state: "{{ states('sensor.bitshake_smartmeterreader_ertrag_pv_alt') | float(2)  + 56120.32 | float(2) }}"

Ich habe dann versucht, die Ausreißer abzufangen, indem ich das State Argument so verändert habe:

state: >
  {% set new_value = states('sensor.bitshake_smartmeterreader_ertrag_pv_alt') | float(2)  + 56120.32 | float(2) %}
  {% set old_value = states('sensor.gesamtertrag_pv_alt') | float(2) %}
  {# Neuer Wert wird ignoriert, wenn die Werte gleich sind oder weil er nicht kleiner sein kann als alter Wert #}
  {% if new_value <= old_value %}
    {{ old_value }}
  {# Wenn mehr als 0,5 kWh hinzugekommen -> wird als Ausreißer betrachtet und alter Wert genommen #}
  {% elif new_value - old_value > 0.5 %}
    {{ old_value }}
  {# Normale Werte #}
  {% else %}
    {{ new_value }}
  {% endif %}

Im ersten Moment schien das zu funktionieren, aber dann hat's den Gesamtertrag, also den Zählerstand genullt, obwohl die Zahlen das nicht hergaben.

sensor.bitshake_smartmeterreader_ertrag_pv_alt hatte 6827,28, macht mit der Addiion von den historischen 56120,32 62947,6 für new_value .
Der Zählerstand vor der Nullung, also old_value, war ebenfalls 62947,6.

Also hätte imho doch {% if new_value <= old_value %}{{ old_value }} greifen müssen, und das wäre eben weiterhin 62947,6 gewesen 🤷‍♂️

Warum funktioniert das nicht? Warum nullt es mir den Zählerstand? 🤷‍♂️

#Hausautomation #Homeserver

#homeasistant #ausreißer #entitaten #ha #hausautomation #homeserver

Crazy-to-Bike @[email protected] · 2026-08-08 · 08:02 UTC

Ich habe bei #Homeasistant schon seit langem den unschönen Effekt, dass bei Neuladen der Konfiguration, z.B. nach Änderungen an der configuration.yaml, #Ausreißer entstehen. Dies betrifft ausschließlich #Entitäten, die ich in der configuration.yaml angelegt habe, immer die Gleichen, aber bei Weitem nicht alle.

Leider ergibt sich da immer ein Rattenschwanz, da ich #HA sehr stark für das Erfassen von Werten und Statistiken nutze (deshalb auch aus meiner Calc-Tabelle für die Hausverbäuche etc. historische Daten von der Zeit vor HA importiert habe) und diverse Berechnungen aus anderen Entitäten machen lasse. Wenn eine daran beteiligte Entität einen Ausreißer produziert, haben logischerweise alle daraus berechneten Entitäten ebenfalls Ausreißer. Da das bis vor 2 Versionen von HA wie gesagt immer nur beim Neuladen der Config auftrat, konnte ich gut damit leben.
Seit vorletzer Version von HA produziert es diese Ausweißer aber regelmäßig und nachvollziehbar immer zu denselben Zeitzpunkten: 0 Uhr, 6 Uhr, 12 Uhr, 18 Uhr 🤷‍♂️

Sieht für mich irgendwie nach Bug aus, da ich keine neuen oder geänderten Entitäten angelegt habe 🤔

Ein Beispiel für eine immer betroffene (mein Verdacht, eine der auslösenden) Entität:

- sensor:
      - name: Gesamtertrag PV alt (mit Langzeitkorrektur)
        unique_id: gesamtertrag_pv_alt
        device_class: Energy
        state_class: total_increasing
        unit_of_measurement: "kWh"
        state: "{{ states('sensor.bitshake_smartmeterreader_ertrag_pv_alt') | float(2)  + 56120.32 | float(2) }}"

Ich habe dann versucht, die Ausreißer abzufangen, indem ich das State Argument so verändert habe:

state: >
  {% set new_value = states('sensor.bitshake_smartmeterreader_ertrag_pv_alt') | float(2)  + 56120.32 | float(2) %}
  {% set old_value = states('sensor.gesamtertrag_pv_alt') | float(2) %}
  {# Neuer Wert wird ignoriert, wenn die Werte gleich sind oder weil er nicht kleiner sein kann als alter Wert #}
  {% if new_value <= old_value %}
    {{ old_value }}
  {# Wenn mehr als 0,5 kWh hinzugekommen -> wird als Ausreißer betrachtet und alter Wert genommen #}
  {% elif new_value - old_value > 0.5 %}
    {{ old_value }}
  {# Normale Werte #}
  {% else %}
    {{ new_value }}
  {% endif %}

Im ersten Moment schien das zu funktionieren, aber dann hat's den Gesamtertrag, also den Zählerstand genullt, obwohl die Zahlen das nicht hergaben.

sensor.bitshake_smartmeterreader_ertrag_pv_alt hatte 6827,28, macht mit der Addiion von den historischen 56120,32 62947,6 für new_value .
Der Zählerstand vor der Nullung, also old_value, war ebenfalls 62947,6.

Also hätte imho doch {% if new_value <= old_value %}{{ old_value }} greifen müssen, und das wäre eben weiterhin 62947,6 gewesen 🤷‍♂️

Warum funktioniert das nicht? Warum nullt es mir den Zählerstand? 🤷‍♂️

#Hausautomation #Homeserver

#homeserver #hausautomation #ha #entitaten #ausreißer #homeasistant

Crazy-to-Bike @[email protected] · 2026-08-08 · 08:02 UTC

Ich habe bei #Homeasistant schon seit langem den unschönen Effekt, dass bei Neuladen der Konfiguration, z.B. nach Änderungen an der configuration.yaml, #Ausreißer entstehen. Dies betrifft ausschließlich #Entitäten, die ich in der configuration.yaml angelegt habe, immer die Gleichen, aber bei Weitem nicht alle.

Leider ergibt sich da immer ein Rattenschwanz, da ich #HA sehr stark für das Erfassen von Werten und Statistiken nutze (deshalb auch aus meiner Calc-Tabelle für die Hausverbäuche etc. historische Daten von der Zeit vor HA importiert habe) und diverse Berechnungen aus anderen Entitäten machen lasse. Wenn eine daran beteiligte Entität einen Ausreißer produziert, haben logischerweise alle daraus berechneten Entitäten ebenfalls Ausreißer. Da das bis vor 2 Versionen von HA wie gesagt immer nur beim Neuladen der Config auftrat, konnte ich gut damit leben.
Seit vorletzer Version von HA produziert es diese Ausweißer aber regelmäßig und nachvollziehbar immer zu denselben Zeitzpunkten: 0 Uhr, 6 Uhr, 12 Uhr, 18 Uhr 🤷‍♂️

Sieht für mich irgendwie nach Bug aus, da ich keine neuen oder geänderten Entitäten angelegt habe 🤔

Ein Beispiel für eine immer betroffene (mein Verdacht, eine der auslösenden) Entität:

- sensor:
      - name: Gesamtertrag PV alt (mit Langzeitkorrektur)
        unique_id: gesamtertrag_pv_alt
        device_class: Energy
        state_class: total_increasing
        unit_of_measurement: "kWh"
        state: "{{ states('sensor.bitshake_smartmeterreader_ertrag_pv_alt') | float(2)  + 56120.32 | float(2) }}"

Ich habe dann versucht, die Ausreißer abzufangen, indem ich das State Argument so verändert habe:

state: >
  {% set new_value = states('sensor.bitshake_smartmeterreader_ertrag_pv_alt') | float(2)  + 56120.32 | float(2) %}
  {% set old_value = states('sensor.gesamtertrag_pv_alt') | float(2) %}
  {# Neuer Wert wird ignoriert, wenn die Werte gleich sind oder weil er nicht kleiner sein kann als alter Wert #}
  {% if new_value <= old_value %}
    {{ old_value }}
  {# Wenn mehr als 0,5 kWh hinzugekommen -> wird als Ausreißer betrachtet und alter Wert genommen #}
  {% elif new_value - old_value > 0.5 %}
    {{ old_value }}
  {# Normale Werte #}
  {% else %}
    {{ new_value }}
  {% endif %}

Im ersten Moment schien das zu funktionieren, aber dann hat's den Gesamtertrag, also den Zählerstand genullt, obwohl die Zahlen das nicht hergaben.

sensor.bitshake_smartmeterreader_ertrag_pv_alt hatte 6827,28, macht mit der Addiion von den historischen 56120,32 62947,6 für new_value .
Der Zählerstand vor der Nullung, also old_value, war ebenfalls 62947,6.

Also hätte imho doch {% if new_value <= old_value %}{{ old_value }} greifen müssen, und das wäre eben weiterhin 62947,6 gewesen 🤷‍♂️

Warum funktioniert das nicht? Warum nullt es mir den Zählerstand? 🤷‍♂️

#Hausautomation #Homeserver

#homeasistant #ausreißer #entitaten #ha #hausautomation #homeserver

Hobbyblogging.de @[email protected] · 2026-08-01 · 12:00 UTC

SmartThings wird kostenpflichtig? Gar nicht gut! Als ich die Nachricht direkt nach meinem Urlaub aufgeschnappt habe, war ich erstmal baff. Und ich weiß ehrlich gesagt auch nicht so genau, was danach kommt. Aber klar ist: 4,99 EUR will ich nicht für die API bezahlen. #smartthings #smarthome #techgadgets #hausautomation

#smartthings #smarthome #techgadgets #hausautomation

Hobbyblogging.de @[email protected] · 2026-08-01 · 12:00 UTC

SmartThings wird kostenpflichtig? Gar nicht gut! Als ich die Nachricht direkt nach meinem Urlaub aufgeschnappt habe, war ich erstmal baff. Und ich weiß ehrlich gesagt auch nicht so genau, was danach kommt. Aber klar ist: 4,99 EUR will ich nicht für die API bezahlen. #smartthings #smarthome #techgadgets #hausautomation

#smartthings #smarthome #techgadgets #hausautomation

Hobbyblogging.de @[email protected] · 2026-08-01 · 12:00 UTC

SmartThings wird kostenpflichtig? Gar nicht gut! Als ich die Nachricht direkt nach meinem Urlaub aufgeschnappt habe, war ich erstmal baff. Und ich weiß ehrlich gesagt auch nicht so genau, was danach kommt. Aber klar ist: 4,99 EUR will ich nicht für die API bezahlen. #smartthings #smarthome #techgadgets #hausautomation

#hausautomation #techgadgets #smarthome #smartthings

Hobbyblogging.de @[email protected] · 2026-08-01 · 12:00 UTC

SmartThings wird kostenpflichtig? Gar nicht gut! Als ich die Nachricht direkt nach meinem Urlaub aufgeschnappt habe, war ich erstmal baff. Und ich weiß ehrlich gesagt auch nicht so genau, was danach kommt. Aber klar ist: 4,99 EUR will ich nicht für die API bezahlen. #smartthings #smarthome #techgadgets #hausautomation

#smartthings #smarthome #techgadgets #hausautomation

FediVerseExplorer @[email protected] · 2026-06-22 · 20:52 UTC

Die Trigger #Temperaturen für die Schattenposition der Rollos muss ich nach oben erweitern, weil die alten Werte im vorgesehenen Schaltzeitraum längst überschritten sind...

#HausAutomation

#temperaturen #hausautomation

FediVerseExplorer @[email protected] · 2026-06-22 · 20:52 UTC

Die Trigger #Temperaturen für die Schattenposition der Rollos muss ich nach oben erweitern, weil die alten Werte im vorgesehenen Schaltzeitraum längst überschritten sind...

#HausAutomation

#temperaturen #hausautomation

FediVerseExplorer @[email protected] · 2026-06-22 · 20:52 UTC

Die Trigger #Temperaturen für die Schattenposition der Rollos muss ich nach oben erweitern, weil die alten Werte im vorgesehenen Schaltzeitraum längst überschritten sind...

#HausAutomation

#hausautomation #temperaturen

Crazy-to-Bike @[email protected] · 2026-06-20 · 12:36 UTC

An unserer #Wallbox #Tinkerforge #Warp3 erfolgt die #Ladefreigabe fahrzeugabhängig mit einem #RDIF Chip, so dass wir im #Ladelog die verschiedenen Fahrzeuge unterscheiden können.

Die Fahrzeuge sind auch in #Homeassistant im #EVCC #Addon definiert, allerdings steht dort im Ladelog immer nur Gastfahrzeug. Die Info, welches Fahrzeug (an der Wallbox zugeordnet zu einem spezifische Benutzer) geladen wird, wird / kann offensichtlich nicht über #ModbusTCP / #MQTT ausgelesen (werden). ☹

#Elektromobilität #Elektroauto #EAuto #Hausautomation #SmartHome

#wallbox #tinkerforge #warp3 #ladefreigabe #rdif #ladelog

Crazy-to-Bike @[email protected] · 2026-06-20 · 12:36 UTC

An unserer #Wallbox #Tinkerforge #Warp3 erfolgt die #Ladefreigabe fahrzeugabhängig mit einem #RDIF Chip, so dass wir im #Ladelog die verschiedenen Fahrzeuge unterscheiden können.

Die Fahrzeuge sind auch in #Homeassistant im #EVCC #Addon definiert, allerdings steht dort im Ladelog immer nur Gastfahrzeug. Die Info, welches Fahrzeug (an der Wallbox zugeordnet zu einem spezifische Benutzer) geladen wird, wird / kann offensichtlich nicht über #ModbusTCP / #MQTT ausgelesen (werden). ☹

#Elektromobilität #Elektroauto #EAuto #Hausautomation #SmartHome

#wallbox #tinkerforge #warp3 #ladefreigabe #rdif #ladelog

Crazy-to-Bike @[email protected] · 2026-06-20 · 12:36 UTC

An unserer #Wallbox #Tinkerforge #Warp3 erfolgt die #Ladefreigabe fahrzeugabhängig mit einem #RDIF Chip, so dass wir im #Ladelog die verschiedenen Fahrzeuge unterscheiden können.

Die Fahrzeuge sind auch in #Homeassistant im #EVCC #Addon definiert, allerdings steht dort im Ladelog immer nur Gastfahrzeug. Die Info, welches Fahrzeug (an der Wallbox zugeordnet zu einem spezifische Benutzer) geladen wird, wird / kann offensichtlich nicht über #ModbusTCP / #MQTT ausgelesen (werden). ☹

#Elektromobilität #Elektroauto #EAuto #Hausautomation #SmartHome

#wallbox #tinkerforge #warp3 #ladefreigabe #rdif #ladelog

Crazy-to-Bike @[email protected] · 2026-06-20 · 12:36 UTC

An unserer #Wallbox #Tinkerforge #Warp3 erfolgt die #Ladefreigabe fahrzeugabhängig mit einem #RDIF Chip, so dass wir im #Ladelog die verschiedenen Fahrzeuge unterscheiden können.

Die Fahrzeuge sind auch in #Homeassistant im #EVCC #Addon definiert, allerdings steht dort im Ladelog immer nur Gastfahrzeug. Die Info, welches Fahrzeug (an der Wallbox zugeordnet zu einem spezifische Benutzer) geladen wird, wird / kann offensichtlich nicht über #ModbusTCP / #MQTT ausgelesen (werden). ☹

#Elektromobilität #Elektroauto #EAuto #Hausautomation #SmartHome

#smarthome #hausautomation #eauto #elektroauto #elektromobilitat #mqtt

Crazy-to-Bike @[email protected] · 2026-06-20 · 12:36 UTC

An unserer #Wallbox #Tinkerforge #Warp3 erfolgt die #Ladefreigabe fahrzeugabhängig mit einem #RDIF Chip, so dass wir im #Ladelog die verschiedenen Fahrzeuge unterscheiden können.

Die Fahrzeuge sind auch in #Homeassistant im #EVCC #Addon definiert, allerdings steht dort im Ladelog immer nur Gastfahrzeug. Die Info, welches Fahrzeug (an der Wallbox zugeordnet zu einem spezifische Benutzer) geladen wird, wird / kann offensichtlich nicht über #ModbusTCP / #MQTT ausgelesen (werden). ☹

#Elektromobilität #Elektroauto #EAuto #Hausautomation #SmartHome

#wallbox #tinkerforge #warp3 #ladefreigabe #rdif #ladelog

techUpdate.io @[email protected] · 2026-06-18 · 05:18 UTC

Matter 1.6 vereinfacht die Smart-Home-Einrichtung und verbessert die Vernetzung

https://techupdate.io/smart-home/matter-1-6-vereinfacht-die-smart-home-einrichtung-und-verbessert-die-vernetzung/51244/

#technews #smarthome #matter #nfc #iot #hausautomation

techUpdate.io @[email protected] · 2026-06-18 · 05:18 UTC

Matter 1.6 vereinfacht die Smart-Home-Einrichtung und verbessert die Vernetzung

https://techupdate.io/smart-home/matter-1-6-vereinfacht-die-smart-home-einrichtung-und-verbessert-die-vernetzung/51244/

#technews #smarthome #matter #nfc #iot #hausautomation

techUpdate.io @[email protected] · 2026-06-18 · 05:18 UTC

Matter 1.6 vereinfacht die Smart-Home-Einrichtung und verbessert die Vernetzung

https://techupdate.io/smart-home/matter-1-6-vereinfacht-die-smart-home-einrichtung-und-verbessert-die-vernetzung/51244/

#technews #smarthome #matter #nfc #iot #hausautomation

techUpdate.io @[email protected] · 2026-06-18 · 05:18 UTC

Matter 1.6 vereinfacht die Smart-Home-Einrichtung und verbessert die Vernetzung

https://techupdate.io/smart-home/matter-1-6-vereinfacht-die-smart-home-einrichtung-und-verbessert-die-vernetzung/51244/

#technews #smarthome #matter #nfc #iot #hausautomation

#hausautomation #iot #nfc #matter #smarthome #technews

Ron @[email protected] · 2026-06-17 · 05:59 UTC

Alexa und ich – das ist momentan eine etwas schwierige Beziehung. Das Einzige, was in unserem Smart Home per Sprachbefehl noch wirklich reibungslos läuft, ist die Haussteuerung. Fürs reine Musikhören kommen die Geräte bei uns ohnehin kaum noch zum Einsatz.

Den Echo Show 15 habe ich mittlerweile in Rente geschickt. Seinen Platz hat jetzt ein Raspberry Pi 400 mit einem 43-Zoll-Bildschirm im Hochformat und nachgerüstetem Touch-Interface eingenommen. Der absolute Pluspunkt dieser Eigenbaulösung? Sie spielt keine unerwünschte Werbung ab! Genau das war nämlich das K.-o.-Kriterium für den Show 15.

Nun kam ja der neue Echo Show 11 auf den Markt, und ich gebe zu: Ich war kurz davor, schwach zu werden. Dass die Kamera keine Bewegungsverfolgung mehr bietet – schade, aber verschmerzbar. Dass man den neig- und drehbaren Standfuß separat dazukaufen muss – na gut, geschenkt. Aber die berechtigte Sorge, dass sich auch dieses Gerät früher oder später in eine unfreiwillige Werbetafel verwandelt, hat mich letztlich vom Kauf abgehalten.

Jetzt überlege ich hin und her, ob vielleicht der neue Echo Studio eine Alternative wäre. Der Hauptgrund für das Interesse ist das neue „Alexa+“. Spannend ist das Feature durchaus, allerdings stört mich die aktuelle Umsetzung gewaltig: Man benötigt zwingend ein Gerät der neuesten Generation, nur um es zu aktivieren und zu konfigurieren. Nutzen lässt es sich danach anscheinend problemlos auch auf den älteren Modellen. Da stellt sich mir schon die Frage nach der Kundenfreundlichkeit, denn es wirkt leider so, als wolle man uns Nutzer fast schon zwingen, in neue Hardware zu investieren.

Ehrlich gesagt bin ich davon aktuell ziemlich enttäuscht. Vielleicht ist es wirklich an der Zeit, den Fokus zu verschieben und sich stattdessen mal genauer mit den Gemini-Lautsprechern von Google zu befassen...

#SmartHome #AmazonAlexa #EchoShow #RaspberryPi #DIYProject #Hausautomation #SmartHomeSetup #TechReview #Sprachassistent #GoogleGemini

#smarthome #amazonalexa #echoshow #raspberrypi #diyproject #hausautomation

Jörn Schaars feine Seite @meine-url-ist-laenger-als-deine.de@meine-url-ist-laenger-als-deine.de · 2026-05-17 · 10:22 UTC

JSFP545: Unbill mit elektronischem Gerät

https://meine-url-ist-laenger-als-deine.de/jsfp545/

#arger #carsharing #friedrichstadt #hausautomation #husum #jornunterwegs

Jörn Schaars feine Seite @meine-url-ist-laenger-als-deine.de@meine-url-ist-laenger-als-deine.de · 2026-05-17 · 10:22 UTC

JSFP545: Unbill mit elektronischem Gerät

https://meine-url-ist-laenger-als-deine.de/jsfp545/

#arger #carsharing #friedrichstadt #hausautomation #husum #jornunterwegs

Jörn Schaars feine Seite @meine-url-ist-laenger-als-deine.de@meine-url-ist-laenger-als-deine.de · 2026-05-17 · 10:22 UTC

JSFP545: Unbill mit elektronischem Gerät

https://meine-url-ist-laenger-als-deine.de/jsfp545/

#stpeterording #spielzeug #nerdkram #jornunterwegs #husum #hausautomation