Mit dem FHEM Alexa Connector das Eurotronic SPZB0001 Thermostat steuern

[xTomi93]

Paßt doch schon soweit .

Erster Versuch:

Code Auswählen Erweitern

defmod MQTT2_z2t_ED59_Test MQTT2_DEVICE z2t_ED59
attr MQTT2_z2t_ED59_Test genericDeviceType thermostat
attr MQTT2_z2t_ED59_Test jsonMap Battery:batteryPercent Device:0 BatteryPercentage:0 LocalTemperature:measured-temp OccupiedHeatingSetpoint:desired-temp
attr MQTT2_z2t_ED59_Test model tasmota_zigbee2tasmota_eurotronic_spirit_test
attr MQTT2_z2t_ED59_Test readingList tele/tasmota_DC0320/ED59/SENSOR:.* { $EVENT =~ m,^.*(..Device.+)..$, ?  json2nameValue($1,'',$JSONMAP) : $EVENT =~ m,0xED59.:(.*).., ?  json2nameValue($1,'',$JSONMAP) : undef }
attr MQTT2_z2t_ED59_Test setList desired-temp:slider,5.0,0.5,30.0,1 cmnd/tasmota_DC0320/ZbSend {"Device":"HZ_Kinderzimmer","Write":{"OccupiedHeatingSetpoint": $EVTPART1}}
attr MQTT2_z2t_ED59_Test stateFormat Soll: desired-temp °C Ist: measured-temp °C Batterie: BatteryPercentage %
attr MQTT2_z2t_ED59_Test userReadings valve:PIHeatingDemand.* { int(ReadingsNum($name, 'PIHeatingDemand', 0)/2.55)}
attr MQTT2_z2t_ED59_Test webCmd desired-temp
attr MQTT2_z2t_ED59_Test icon hm-cc-rt-dn
Wie du siehst, ist da einiges rausgeworfen, das IODev musst du eventuell wieder nachfüttern, sonst sollte das eigentlich passen.

Hab das so eingefügt, im Grunde funktioniert das Thermostat allerdings kenn ich das so das PiHeatingDemand die Ventilposition in % anzeigt, wenn ich die Heizung komplett auf 30 grad (maximum) aufdrehe steht bei PiHeatingDemand 98% und bei valve 38%. Hat das ein Grund?

Wenn du setList und jsonMap ansiehst, wirst du sehen, dass da zum einen der "Kreis" in Sende- und Empfangsrichtung geschlossen wurde und einfach dann die in FHEM "üblichen" Benennungen verwendet werden, das sollte eigentlich ein spezielles Mapping komplett überflüssig machen und das Device dann direkt so z.B. für WeekdayTimer/weekprofile direkt verwendbar sein, um Wochenprofile abzubilden und die schnell mal an- und abwesenheitsabhängig tauschen zu können .

ähm.. ja was sowas wie Wochenprofile und Co angeht, soweit bin ich mit meinem SmartHome noch nicht 

Was den Rest angeht, finde ich erst mal dieses Reading interessant:

Code Auswählen Erweitern

setstate MQTT2_z2t_ED59 2020-11-25 06:08:18 0001/003E 0
In binärer Codierung wäre das "3E" "00111110" (62 dezimal), aber da bekomme ich im Moment auch noch keine Brücke zu https://www.zigbee2mqtt.io/devices/SPZB0001.html#controlling gebaut...

Vielleicht loggst du einfach mal eine zeitlang, was so (JSON-encoded) über den betreffenden Topic reinkommt? Dazu kannst du eine weitere Zeile in readingList einfügen:

Code Auswählen Erweitern

tele/tasmota_DC0320/ED59/SENSOR:.* json_raw
und dann das Reading json_raw in ein eigenes FileLog laufen lassen?

ok ist erledigt, gebe rückmeldung wenn sich da was tut.


//Edit:
Hab mich nun bisschen mit der Temperatur rauf runter gestellt um zumindest paar einträge zu provozieren ob ich überhaupt alles mit der FileLog richtig gemacht habe und ja das kam bisher raus.

Code Auswählen Erweitern

2020-11-25_21:54:38 MQTT2_z2t_ED59_Test json_raw: {"ZbReceived":{"HZ_Kinderzimmer":{"Device":"0xED59","Name":"HZ_Kinderzimmer","PIHeatingDemand":91,"Endpoint":1,"LinkQuality":50}}}
2020-11-25_21:54:39 MQTT2_z2t_ED59_Test json_raw: {"ZbReceived":{"HZ_Kinderzimmer":{"Device":"0xED59","Name":"HZ_Kinderzimmer","OccupiedHeatingSetpoint":5,"Endpoint":1,"LinkQuality":60}}}
2020-11-25_21:54:44 MQTT2_z2t_ED59_Test json_raw: {"ZbReceived":{"HZ_Kinderzimmer":{"Device":"0xED59","Name":"HZ_Kinderzimmer","LocalTemperature":25.5,"PIHeatingDemand":0,"OccupiedHeatingSetpoint":5,"UnoccupiedHeatingSetpoint":16,"Endpoint":1,"LinkQuality":50}}}
2020-11-25_21:55:13 MQTT2_z2t_ED59_Test json_raw: {"ZbReceived":{"HZ_Kinderzimmer":{"Device":"0xED59","Name":"HZ_Kinderzimmer","LocalTemperature":25.5,"PIHeatingDemand":18,"OccupiedHeatingSetpoint":26,"UnoccupiedHeatingSetpoint":16,"Endpoint":1,"LinkQuality":34}}}
2020-11-25_21:55:40 MQTT2_z2t_ED59_Test json_raw: {"ZbReceived":{"HZ_Kinderzimmer":{"Device":"0xED59","Name":"HZ_Kinderzimmer","PIHeatingDemand":18,"Endpoint":1,"LinkQuality":42}}}
2020-11-25_21:55:46 MQTT2_z2t_ED59_Test json_raw: {"ZbReceived":{"HZ_Kinderzimmer":{"Device":"0xED59","Name":"HZ_Kinderzimmer","OccupiedHeatingSetpoint":26,"Endpoint":1,"LinkQuality":55}}}
2020-11-25_21:55:58 MQTT2_z2t_ED59_Test json_raw: {"ZbReceived":{"HZ_Kinderzimmer":{"Device":"0xED59","Name":"HZ_Kinderzimmer","CurrentTemperatureSetPoint":26,"Endpoint":1,"LinkQuality":42}}}
2020-11-25_21:56:04 MQTT2_z2t_ED59_Test json_raw: {"ZbReceived":{"HZ_Kinderzimmer":{"Device":"0xED59","Name":"HZ_Kinderzimmer","UnoccupiedHeatingSetpoint":16,"Endpoint":1,"LinkQuality":39}}}
2020-11-25_21:56:40 MQTT2_z2t_ED59_Test json_raw: {"ZbReceived":{"HZ_Kinderzimmer":{"Device":"0xED59","Name":"HZ_Kinderzimmer","PIHeatingDemand":9,"Endpoint":1,"LinkQuality":45}}}
2020-11-25_21:57:56 MQTT2_z2t_ED59_Test json_raw: {"ZbReceived":{"HZ_Kinderzimmer":{"Device":"0xED59","Name":"HZ_Kinderzimmer","LocalTemperature":22.5,"PIHeatingDemand":9,"OccupiedHeatingSetpoint":26,"UnoccupiedHeatingSetpoint":16,"Endpoint":1,"LinkQuality":47}}}
2020-11-25_21:58:00 MQTT2_z2t_ED59_Test json_raw: {"ZbReceived":{"HZ_Kinderzimmer":{"Device":"0xED59","Name":"HZ_Kinderzimmer","LocalTemperature":22.5,"Endpoint":1,"LinkQuality":45}}}
2020-11-25_21:58:06 MQTT2_z2t_ED59_Test json_raw: {"ZbReceived":{"HZ_Kinderzimmer":{"Device":"0xED59","Name":"HZ_Kinderzimmer","PIHeatingDemand":77,"Endpoint":1,"LinkQuality":50}}}

Da ich ja nen Seperaten Temperatur Sensor habe muss ich mein Thermostat nach jedem Reset neu Kalibrieren das mache ich mittels diesen Code

Code Auswählen Erweitern

{"Device":"HZ_Kinderzimmer","Write":{"LocalTemperatureCalibration":-3}}

das interessante an dem ist in dem aktuel Json_Raw ausschnitt ist zwar zu sehen wie dann die Local Temperatur von 25.5 auf 22.5 fällt allerdings ist im Payload kein Eintrag vorhanden bezüglich "LocalTemperaturCalibration": -3, bei zigbee2mqtt wenn ich das gemacht habe wurde bei jedem payload den mir das thermostat gesendet hat dieser wert angezeigt und auch ein dementsprechendes reading gesetzt in FHEM, Zigbee2Tasmota ignoriert das einfach komplett, es funktioniert zwar aber falls ich ja mal in ein paar Monaten das noch einmal nachstellen möchte weiß ich ja nicht welcher Wert aktuell gesetzt ist

[Beta-User]

[...]PiHeatingDemand 98% und bei valve 38%. Hat das ein Grund?

, falscher Schluss von z2m auf z2t; hier darf man wohl nicht rechnen, das macht tasmota schon => kein userReading, weiteres jsonMap

ähm.. ja was sowas wie Wochenprofile und Co angeht, soweit bin ich mit meinem SmartHome noch nicht 

Kein Ding, deswegen gibt's ja Leute, die sich u.a. mit "guten" Readingnamen befassen...

Hab mich nun bisschen mit der Temperatur rauf runter gestellt um zumindest paar einträge zu provozieren ob ich überhaupt alles mit der FileLog richtig gemacht habe und ja das kam bisher raus.

Sieht schon mal sehr gut aus, das bitte dann auch wieder einfügen/loggen, ansonsten käme erst mal folgendes Zwischenergebnis raus:

Code Auswählen Erweitern

defmod MQTT2_z2t_ED59_Test MQTT2_DEVICE z2t_ED59
attr MQTT2_z2t_ED59_Test genericDeviceType thermostat
attr MQTT2_z2t_ED59_Test jsonMap Battery:batteryPercent Device:0 BatteryPercentage:0 LocalTemperature:measured-temp OccupiedHeatingSetpoint:dayTemp UnoccupiedHeatingSetpoint:nightTemp CurrentTemperatureSetPoint:desired-temp PIHeatingDemand:valve
attr MQTT2_z2t_ED59_Test model tasmota_zigbee2tasmota_eurotronic_spirit_test
attr MQTT2_z2t_ED59_Test readingList tele/tasmota_DC0320/ED59/SENSOR:.* { $EVENT =~ m,^.*(..Device.+)..$, ?  json2nameValue($1,'',$JSONMAP) : $EVENT =~ m,0xED59.:(.*).., ?  json2nameValue($1,'',$JSONMAP) : undef }
attr MQTT2_z2t_ED59_Test setList desired-temp:slider,5.0,0.5,30.0,1 cmnd/tasmota_DC0320/ZbSend {"Device":"HZ_Kinderzimmer","Write":{"OccupiedHeatingSetpoint": $EVTPART1}}\
  temp-offset:slider,5.0,0.5,30.0,1 cmnd/tasmota_DC0320/ZbSend  {"Device":"HZ_Kinderzimmer","Write":{"LocalTemperatureCalibration":$EVTPART1}}
attr MQTT2_z2t_ED59_Test stateFormat Soll: desired-temp °C Ist: measured-temp °C Batterie: BatteryPercentage %
attr MQTT2_z2t_ED59_Test setStateList on off
attr MQTT2_z2t_ED59_Test webCmd desired-temp
attr MQTT2_z2t_ED59_Test icon hm-cc-rt-dnBitte teste mal, ob du statt auf "OccupiedHeatingSetpoint" in

Code Auswählen Erweitern

desired-temp:slider,5.0,0.5,30.0,1 cmnd/tasmota_DC0320/ZbSend {"Device":"HZ_Kinderzimmer","Write":{"OccupiedHeatingSetpoint": $EVTPART1}}
"CurrentTemperatureSetPoint" als Ziel angeben kannst und das dann noch funktioniert. Wenn ja, könnte man die setList um zwei Zeilen erweitern, du ahnst hoffentlich schon, welche?
Dann fehlt noch eine, um zwischen Tag und Nacht umzuschalten, aber da fehlt mir noch das "Ziel".

das interessante an dem ist in dem aktuel Json_Raw ausschnitt ist zwar zu sehen wie dann die Local Temperatur von 25.5 auf 22.5 fällt allerdings ist im Payload kein Eintrag vorhanden bezüglich "LocalTemperaturCalibration": -3, bei zigbee2mqtt wenn ich das gemacht habe wurde bei jedem payload den mir das thermostat gesendet hat dieser wert angezeigt und auch ein dementsprechendes reading gesetzt in FHEM, Zigbee2Tasmota ignoriert das einfach komplett, es funktioniert zwar aber falls ich ja mal in ein paar Monaten das noch einmal nachstellen möchte weiß ich ja nicht welcher Wert aktuell gesetzt ist

Mit dem "Trick" setStateList sollte zumindest was in einem passenden Reading landen, auch, wenn es noch keine Rückgabe gibt. Vermutlich muss man das aktiv abfragen, dafür bräuchten wir aber erst mal die bekannten Endpoints usw..
Falls du schon ein gewisses "Gefühl" hast, wie das in etwa gehen könnte, müßte in https://tasmota.github.io/docs/Zigbee/#device-information (bzw. dem folgenden Abschnitt) was zu finden sein. Kann sein, dass du dazu dann auch die passenden RAW-JSON an der bridge irgendwie loggen musst (bitte auf einen passenden Filter achten, damit nicht alle RAW-JSON von allen Devices im Log landen, wir sollten erst mal nur bei einem Device bleiben...).

[xTomi93]

Sieht schon mal sehr gut aus, das bitte dann auch wieder einfügen/loggen, ansonsten käme erst mal folgendes Zwischenergebnis raus:

ok

"CurrentTemperatureSetPoint" als Ziel angeben kannst und das dann noch funktioniert. Wenn ja, könnte man die setList um zwei Zeilen erweitern, du ahnst hoffentlich schon, welche?

Ich gehe mal davon aus um Tag und Nacht Temperatur einzeln einstellen zu können?
Aber leider geht das nicht, das habe ich aber auch bei Z2M schonmal probiert und aktuell wieder diesen Wert kann ich zwar ansteuern, aber das Thermostat selber reagiert darauf nicht.

Dann fehlt noch eine, um zwischen Tag und Nacht umzuschalten, aber da fehlt mir noch das "Ziel".
Mit dem "Trick" setStateList sollte zumindest was in einem passenden Reading landen, auch, wenn es noch keine Rückgabe gibt. Vermutlich muss man das aktiv abfragen, dafür bräuchten wir aber erst mal die bekannten Endpoints usw..
Falls du schon ein gewisses "Gefühl" hast, wie das in etwa gehen könnte, müßte in https://tasmota.github.io/docs/Zigbee/#device-information (bzw. dem folgenden Abschnitt) was zu finden sein. Kann sein, dass du dazu dann auch die passenden RAW-JSON an der bridge irgendwie loggen musst (bitte auf einen passenden Filter achten, damit nicht alle RAW-JSON von allen Devices im Log landen, wir sollten erst mal nur bei einem Device bleiben...).

Hab zwar aktuell noch keine Ahnung wie ich das machen soll, werde es aber heute nach der Spätschicht mal versuchen herauszufinden.

Code Auswählen Erweitern

temp-offset:slider,5.0,0.5,30.0,1 cmnd/tasmota_DC0320/ZbSend  {"Device":"HZ_Kinderzimmer","Write":{"LocalTemperatureCalibration":$EVTPART1}}

Ich habe mich ein bisschen damit herumgespielt, wird sicherlich auch im JSON_Raw ersichtlich sein in welchem Bereich die Kalibrierung funktioniert, mein letzter Stand war 0 +- 5 (aber das kann auch bei einem anderen Thermostat gewesen sein das ich vorher mal hatte) durch ein bisschen probieren habe ich festgestellt es geht im Bereich 0 +-10°C also habe ich den Slider wie folgt angepasst.

Code Auswählen Erweitern

temp-offset:slider,-10.0,0.5,10.0,1 cmnd/tasmota_DC0320/ZbSend  {"Device":"HZ_Kinderzimmer","Write":{"LocalTemperatureCalibration":$EVTPART1}}


Im Anhang befindet sich die Aktuelle Log Datei.

[Beta-User]

Sorry wg. des Flüchtigkeitsdingens an "offset"...

Tendenziell ist z2m "intelligenter" als z2t. Von daher würde ich nicht vorschnell vom einen auf das andere schließen - was aber nicht heißt, dass es wirklich auf diese Weise klappt. Eventuell muss man wirklich "hex-payload" erzeugen, und selbst für die Auswertung sorgen (das betrifft dann auch diese "manufacurer specific"-Geschichten).
Für den Aqara vibration ist das hier eigentlich ganz gut beschrieben, wie man "irgendwas" schreibt und liest: https://tasmota.github.io/docs/Zigbee/#aqara-vibration-sensor

Das log schaue ich mir bei Gelegenheit mal durch, allerding bin ich auch ziemlicher noob, was sowas angeht...

[xTomi93]

Sorry wg. des Flüchtigkeitsdingens an "offset"...

Kein Ding 

Ich habe mal über die Tasmota Console ZbStatus 1-3 und ZbProbe ausgeführt und foldendes erhalten

Code Auswählen Erweitern

2020-11-27_10:32:40 MQTT2_DVES_DC0320 ZbStatus1: {"ZbStatus1":[{"Device":"0xED59","Name":"HZ_Kinderzimmer"}]}
2020-11-27_10:32:57 MQTT2_DVES_DC0320 ZbStatus1: {"ZbStatus1":[{"Device":"0xED59","Name":"HZ_Kinderzimmer"}]}
2020-11-27_10:33:06 MQTT2_DVES_DC0320 ZbStatus2: {"ZbStatus2":[{"Device":"0xED59","Name":"HZ_Kinderzimmer","IEEEAddr":"0x00158D00053D2D4A","ModelId":"SPZB0001","Manufacturer":"Eurotronic","Endpoints":[1],"Config":["T01"]}]}
2020-11-27_10:33:11 MQTT2_DVES_DC0320 ZbStatus3: {"ZbStatus3":[{"Device":"0xED59","Name":"HZ_Kinderzimmer","IEEEAddr":"0x00158D00053D2D4A","ModelId":"SPZB0001","Manufacturer":"Eurotronic","Endpoints":[1],"Config":["T01"],"ThSetpoint":4,"TempTarget":22,"Temperature":22,"Reachable":true,"BatteryPercentage":20,"LastSeen":28,"LastSeenEpoch":1606469562,"LinkQuality":60}]}
2020-11-27_10:33:47 MQTT2_DVES_DC0320 ZbProbe: Done
2020-11-27_10:33:48 MQTT2_DVES_DC0320 ZbPing_Name: HZ_Kinderzimmer
2020-11-27_10:33:48 MQTT2_DVES_DC0320 ZbPing_IEEEAddr: 0x00158D00053D2D4A
2020-11-27_10:33:48 MQTT2_DVES_DC0320 ZbPing_Device: 0xED59
2020-11-27_10:33:48 MQTT2_DVES_DC0320 ZbState_Status: 32
2020-11-27_10:33:48 MQTT2_DVES_DC0320 ZbState_ActiveEndpoints_1: 0x01
2020-11-27_10:33:55 MQTT2_DVES_DC0320 ZbState_Endpoint: 0x01
2020-11-27_10:33:55 MQTT2_DVES_DC0320 ZbState_InClusters_6: 0x000A
2020-11-27_10:33:55 MQTT2_DVES_DC0320 ZbState_OutClusters_7: 0x000A
2020-11-27_10:33:55 MQTT2_DVES_DC0320 ZbState_OutClusters_2: 0x0001
2020-11-27_10:33:55 MQTT2_DVES_DC0320 ZbState_InClusters_2: 0x0001
2020-11-27_10:33:55 MQTT2_DVES_DC0320 ZbState_OutClusters_3: 0x0003
2020-11-27_10:33:55 MQTT2_DVES_DC0320 ZbState_DeviceId: 0x0301
2020-11-27_10:33:55 MQTT2_DVES_DC0320 ZbState_InClusters_4: 0x0201
2020-11-27_10:33:55 MQTT2_DVES_DC0320 ZbState_InClusters_5: 0x0019
2020-11-27_10:33:55 MQTT2_DVES_DC0320 ZbState_ProfileId: 0x0104
2020-11-27_10:33:55 MQTT2_DVES_DC0320 ZbState_OutClusters_1: 0x0000
2020-11-27_10:33:55 MQTT2_DVES_DC0320 ZbState_OutClusters_6: 0x0019
2020-11-27_10:33:55 MQTT2_DVES_DC0320 ZbState_OutClusters_5: 0x0201
2020-11-27_10:33:55 MQTT2_DVES_DC0320 ZbState_DeviceVersion: 1
2020-11-27_10:33:55 MQTT2_DVES_DC0320 ZbState_InClusters_3: 0x0003
2020-11-27_10:33:55 MQTT2_DVES_DC0320 ZbState_OutClusters_4: 0x0004
2020-11-27_10:33:55 MQTT2_DVES_DC0320 ZbState_Status: 33
2020-11-27_10:33:55 MQTT2_DVES_DC0320 ZbState_InClusters_1: 0x0000
2020-11-27_10:34:02 MQTT2_DVES_DC0320 ZbBind_Name: HZ_Kinderzimmer
2020-11-27_10:34:02 MQTT2_DVES_DC0320 ZbBind_StatusMessage: SUCCESS
2020-11-27_10:34:02 MQTT2_DVES_DC0320 ZbBind_Device: 0xED59
2020-11-27_10:34:02 MQTT2_DVES_DC0320 ZbBind_Status: 0
2020-11-27_10:34:02 MQTT2_DVES_DC0320 ZbBind_Status: 0
2020-11-27_10:34:02 MQTT2_DVES_DC0320 ZbBind_Device: 0xED59
2020-11-27_10:34:02 MQTT2_DVES_DC0320 ZbBind_StatusMessage: SUCCESS
2020-11-27_10:34:02 MQTT2_DVES_DC0320 ZbBind_Name: HZ_Kinderzimmer

[Beta-User]

hmmm, sooo, ja also...?!?

Ist ja schön, dass da was kommt, aber im Moment muss ich zugeben, dass mir das nüscht sacht... Vermutlich müsste da mal jemand mit "hex-converter-Augen" drüber sehen.
Du könntest auf die gemeldeten Endpunkte mal "Read" ausführen, wie  im Tasmota-Wiki bei "There will be no response to the command but you can check if the new option is active by using [...]" beschrieben. Kann aber nicht sagen, ob da was kommt, und ob man damit mehr anfangen kann wie mit dem aus dem Log.

Aus dem fand ich noch interessant,
- dass da recht genau alle 20 Min was unter 0201/4008 kam; 0x4008 war doch genau die "manufacturer-specific" Adresse (jetzt nach Zeile 1654 gewandert, und 0201 wäre dann in binär 0010 0001 (? oder 00000010 00000001). Wenn man das in der vierstelligen Variante rückwärts liest (ausgehend von der Angabe bei https://www.zigbee2mqtt.io/devices/SPZB0001.html#controlling, dass die erste Ziffer immer 1 ist), dann wäre das eine Fenster-Offen-Meldung...? Aber alle 20 Minuten ohne gegenläufige Info? Wäre komisch. Vielleicht reißt du mal das Fenster auf und kuckst, was dann passiert... Vielleicht ändert sich ja tatsächlich der hintere der beiden Werte?

- dieses 0019!01 um 11:19:01 Uhr. Irgendeine Idee? (Vielleicht hat ja jemand eine Idee, was der zugehörige Wert sein könnte - 0037100C11D2E96201, mit https://www.rapidtables.com/convert/number/hex-to-ascii.html kam - wenig überrschend - nichts raus, was man direkt verwenden könnte...)

[xTomi93]

hmmm, sooo, ja also...?!?

Ist ja schön, dass da was kommt, aber im Moment muss ich zugeben, dass mir das nüscht sacht... Vermutlich müsste da mal jemand mit "hex-converter-Augen" drüber sehen.
Du könntest auf die gemeldeten Endpunkte mal "Read" ausführen, wie  im Tasmota-Wiki bei "There will be no response to the command but you can check if the new option is active by using [...]" beschrieben. Kann aber nicht sagen, ob da was kommt, und ob man damit mehr anfangen kann wie mit dem aus dem Log.

hä? 

Aus dem fand ich noch interessant,
- dass da recht genau alle 20 Min was unter 0201/4008 kam; 0x4008 war doch genau die "manufacturer-specific" Adresse (jetzt nach Zeile 1654 gewandert, und 0201 wäre dann in binär 0010 0001 (? oder 00000010 00000001). Wenn man das in der vierstelligen Variante rückwärts liest (ausgehend von der Angabe bei https://www.zigbee2mqtt.io/devices/SPZB0001.html#controlling, dass die erste Ziffer immer 1 ist), dann wäre das eine Fenster-Offen-Meldung...? Aber alle 20 Minuten ohne gegenläufige Info? Wäre komisch. Vielleicht reißt du mal das Fenster auf und kuckst, was dann passiert... Vielleicht ändert sich ja tatsächlich der hintere der beiden Werte?

Die Automatische Fenster Offen Erkennung funktioniert nicht, hab das Fenter ca. 30 Minuten offen gehabt und normal sollte das Thermostat nach 15 Minuten in den Fenster Offen Modus schalten, aber ich denke das wird von der Bridge geregelt und die OEM Bridge hab ich nicht und in Zigbee2MQTT kann man es manuell regeln.

Ich habe versucht per Payload den Wert manuell zu ändern aber das geht nicht ich krieg immer die Meldung

Code Auswählen Erweitern


{"Device":"HZ_Kinderzimmer","Write":{"0201/4008":0x05}}
{"Device":"HZ_Kinderzimmer","Write":{"0201/4008":5}}


stat/tasmota_DC0320/RESULT = {"ZbSend":"Unknown attribute type for attribute '�


5 Soll ja demnach heißen das das der FensterOffen Modus aktiv ist.
Hab ich den Wert evtl. Falsch eingegeben? Keine Ahnung.

- dieses 0019!01 um 11:19:01 Uhr. Irgendeine Idee? (Vielleicht hat ja jemand eine Idee, was der zugehörige Wert sein könnte - 0037100C11D2E96201, mit https://www.rapidtables.com/convert/number/hex-to-ascii.html kam - wenig überrschend - nichts raus, was man direkt verwenden könnte...)

ähm.. nein

Meine Idee wäre es irgendwie den zigbee-herdman-converter irgendwie in Zigbee2Tasmota zu integrieren, dieser Regelt auch bei Zigbee2MQTT die ganze geschichte.

[Beta-User]

Das mit der automatischen Fenster-offen-Erkennung ist m.E. eine firmware-Geschichte und ohne spezielles Setting von der Controller-Seite her sollte das automatisch klappen (ggf. nach einem factory-reset, wenn mal per Controller "Fenster-auf" gesetzt war; das könnte diese Automatik ausschalten, so sie denn überhaupt eingebaut ist (?)). Ist aber alles nur Spekulation...

Erweiterte Controller-Funktionalität sollte man von einem ESP8266 nicht erwarten, da reicht schlicht die Rechenkapazität nicht; falls das je mal jemand auf ESP32 portiert, sieht es ggf. anders aus. Mein überschlägiger Eindruck beim Überfliegen der diversen Projekte: Man will sich auf wenige Kombinationen Software/Interface beschränken, und diese dann lieber richtig bearbeiten (siehe z.B. ConBee II in zigbee2mqtt und den Thread zur Integration von zigbee in Tasmota). Macht m.E. Sinn...

Habe jetzt auch mal eine Sonoff-Bridge umgeflasht und werde ggf. bei Gelegenheit mal damit etwas rumspielen, aber im Moment bin ich dann erst mal ratlos, was den Spirit angeht.

Unseren (ja durchaus nutzbaren) Zwischenstand zum Spirit findest du im nächsten update der mqtt2.template.

Jetzt muss ich erst mal ein ganz anderes Problem fixen...

[xTomi93]

Das mit der automatischen Fenster-offen-Erkennung ist m.E. eine firmware-Geschichte und ohne spezielles Setting von der Controller-Seite her sollte das automatisch klappen (ggf. nach einem factory-reset, wenn mal per Controller "Fenster-auf" gesetzt war; das könnte diese Automatik ausschalten, so sie denn überhaupt eingebaut ist (?)). Ist aber alles nur Spekulation...

Das Ding ist ich kann es nicht testen, lt. Eurotronic hat das ding die Automatische Erkennung da es per Taste nicht möglich ist diesen Modus Manuell zu aktivieren.
Ohne Verbindung zu einer Zigbee-Bridge kann der Eurotronic nicht verwendet werden er hängt im Join-Modus fest und das wars
Mit einem CC2531 und Zigbee2MQTT auf dem Raspberry ist es ja möglich diesen Modus manuell zu aktiveren, automatisch egal wie lang das fenster offen ist passiert da nichts
Mit einer Sonoff Bridge und Zigbee2Tastmota ist es leider nicht möglich diesen Modus manuell zu aktivieren wie wir ja bis dato festgestellt haben und automatisch da auch nichts wenn das Fenster offen ist.

lt. Eurotronic gibt es auch keine Eigene Bridge in der Anleitung wird nur gezeigt wie man es mit dem Amazon Echo Plus oder Echo Show koppeln kann. Dort habe ich auch diesen ausschnitt gefunden.

Im Stellwertbetrieb (Manufacturer-Specific-Mode) wird die Fenster-Offen Erkennung nicht ausgeführt

Könnte das bedeuten das dieser Manufacturer-Specific-Mode standard mäßig aktiv ist bei einer Verbindung mit Zigbee2Tastmota?

Erweiterte Controller-Funktionalität sollte man von einem ESP8266 nicht erwarten, da reicht schlicht die Rechenkapazität nicht; falls das je mal jemand auf ESP32 portiert, sieht es ggf. anders aus. Mein überschlägiger Eindruck beim Überfliegen der diversen Projekte: Man will sich auf wenige Kombinationen Software/Interface beschränken, und diese dann lieber richtig bearbeiten (siehe z.B. ConBee II in zigbee2mqtt und den Thread zur Integration von zigbee in Tasmota). Macht m.E. Sinn...

Habe jetzt auch mal eine Sonoff-Bridge umgeflasht und werde ggf. bei Gelegenheit mal damit etwas rumspielen, aber im Moment bin ich dann erst mal ratlos, was den Spirit angeht.

Das heißt?

Unseren (ja durchaus nutzbaren) Zwischenstand zum Spirit findest du im nächsten update der mqtt2.template.

Eine Sache ist mir dann noch aufgefallen.
Seit ich das Template "tasmota_zigbee2tasmota_generic_battery_sensor" aktiviert habe bei den Heizungsthermostaten sowohl auch bei den aqara Sensoren für Temperatur und Luftfeuchte, wird der Batterie status nicht mehr abgefragt, aktualisiert oder überhaupt ein Reading erstellt ohne Template hat dies aber funktioniert. Was kann der Grund sein?

Jetzt muss ich erst mal ein ganz anderes Problem fixen...

hmm.. oke

[Beta-User]

Das Ding ist ich kann es nicht testen, lt. Eurotronic hat das ding die Automatische Erkennung da es per Taste nicht möglich ist diesen Modus Manuell zu aktivieren.

Soweit ist es klar...

Ohne Verbindung zu einer Zigbee-Bridge kann der Eurotronic nicht verwendet werden er hängt im Join-Modus fest und das wars
Mit einem CC2531 und Zigbee2MQTT auf dem Raspberry ist es ja möglich diesen Modus manuell zu aktiveren, automatisch egal wie lang das fenster offen ist passiert da nichts

Also: Das Teil hat irgendwo einen Bereich, in dem die Einstellungen gespeichert werden. Ob die jeweils bei einem "join" komplett auf "default" zurückgestellt werden: keine Ahnung, häufig ist das nicht der Fall.

Dass zigbee2mqtt eher ein vollwertiger Dienst ist, ist klar, wie gesagt, die Rechenleistung des ESP8266 (u.A. der Microcontroller auf der Sonoff-Bridge) ist zu gering, um wesentlich mehr zu machen wie "Informationen zu makeln".

Daher müßte es eben in FHEM die "Logik" geben, wie man den "Fenster-ist-offen-Wert" (oder den "Stellwertmodus") aktiviert. Wie gesehen: wenn es überhaupt geht, wissen wir nicht, wie die Befehle aussehen müssten.

Könnte das bedeuten das dieser Manufacturer-Specific-Mode standard mäßig aktiv ist bei einer Verbindung mit Zigbee2Tastmota?

Eher nicht, und in den anderen Varianten wird dieser spezielle Modus auch wieder verlassen, sobald man eine Solltemperatur vorgibt. Glaube nicht, dass das hier anders ist.

Das heißt?

Dass ich auch erst mal nicht weiter weiß und ggf. aber ein (anderes) Device habe, um ein wenig zu spielen.

Eine Sache ist mir dann noch aufgefallen.
Seit ich das Template "tasmota_zigbee2tasmota_generic_battery_sensor" aktiviert habe bei den Heizungsthermostaten sowohl auch bei den aqara Sensoren für Temperatur und Luftfeuchte, wird der Batterie status nicht mehr abgefragt, aktualisiert oder überhaupt ein Reading erstellt ohne Template hat dies aber funktioniert. Was kann der Grund sein?

Irgendwas ist mit der Auswertung komisch, ich weiß aber noch nicht was, oder beim neu Pairen wird die ID geändert (=> anderes Device vorhanden?). Evtl. hat sich da was an der Tasmota-firmware geändert, ich habe da jetzt betr. Battery teilweise im jsonMap angepaßt, aber eigentlich müssten zumindest "normale Readings" durchkommen. Die Motion-Dinger basieren jedenfalls auch auf dem "generic battery", und das hatte vorhin funktioniert...

Habe aber wie gesagt grade auch nicht die Zeit, das intensiver anzusehen.