Zigbee2MQTT - Template für Thermostat

[Snocksman]

Ich warte jetzt erstmal ab, bis ich dieses Tuya-Gateway bekommen habe (in der Hoffnung, dass es da wirklich ein Firmwareupdate für die Thermostate gibt)... Das Thermostat läuft nämlich mehr als bescheiden. Selbst wenn ich es mal soweit habe, dass es änderungen aus FHEM heraus annimmt, tut es das nur sehr unzuverlässig; Ich würde mal sagen, dass ca. 60% der Temperaturänderungen durch geht, der Rest wird scheinbar vom Thermostat ignoriert. Und zwischenzeitlich versagt es dann mal wieder komplett den Dienst.

Was mich trotzdem noch interessieren würde: Wie führe ich ein unpairing eines Devices durch ?

[Beta-User]

Würde auf den "remove"-Kommand tippen. Aber frag' mich nicht, wie man den verwendet, ich hatte das damals nur nach den Kommandos abgebildet, die bei zigbee2mqtt in der damaligen Doku zu finden waren; bisher hat sich keiner beschwert...

Generell noch:
- allgemeine Probleme fände ich in einem separaten Thread (im Zigbee-Bereich) besser aufgehoben;- CC2531 ist kein optimales IO, das ist einfach "zu klein";
- ich _vermute_, das Problem ist bei dem Thermostaten _auch_, dass da viele Datenpunkte sind, was entsprechend Speicher auf den Coordinator beansprucht. Es _könnte_ sein, dass die Aussage "16 oder 17" Geräte hätten auf dem CC2531 Platz stark davon abhängig ist, wieviele "endpoints" tatsächlich vorhanden sind, so dass evt. 13 oder 14 + das Thermostat "too much" sein könnten.

- "unpairing" "braucht" man nur dann, wenn das Device später nicht wieder an diesem IO gepairt werden soll, ansonsten kann man das recht beliebig hin- und her umziehen (verliert aber etwas Speicher auf dem Coordinator-Chip, wenn man das nicht explizit wieder freigibt...)

Also falls du ZigBee ausbauen willst, und noch einen CC253x verwendest: alsbald Ersatz beschaffen; der ist nur für kleine Installationen ok.


Sorry für das mit dem "x_send_set_payload:textField":Da fehlt in der Zeile vorher ein "\" als escape-Zeichen für den Zeilenumbruch. Bitte erst mal manuell nachpflegen und dann {AttrTemplate_Initialize()} ausführen.

[Snocksman]

Also bei dem remove command meinst du in dem MQTT2_zigbee_bridge Device ? Da gibt es remove, wo ich danach ein Eingabefeld habe... Da wäre dann die Frage, was da rein soll (Ich würde mal auf 0xbc33acfffe45850a tippen ?) Ich war am schwanken, zwischen remove, oder x_bind_unbind...

Ich setze übrigens einen Conbee II Stick ein, der sollte doch genug Power haben...? An Devices habe ich bislang:
1x Philips HUE CCT Bulb
6x Osram Zwischenstecker
1x Diesen Lichtschalter https://de.aliexpress.com/item/4001138076397.html?spm=a2g0s.9042311.0.0.15d74c4dhpADAa
1x Diesen Helligkeitssensor https://de.aliexpress.com/item/1005001700532972.html?spm=a2g0s.9042311.0.0.15d74c4dhpADAa

...und eben das Thermostat.

Die Zwischenstecker, der Schalter und die HUE Bulb funktionieren ohne Probleme. Der Helligkeitssensor hat, vermute ich, ein kleines Distanzproblem... Er meldet zwar Werte, aber ein wenig unregelmäßig.

[Beta-User]

Wie das im Einzelnen mit den Befehlen ist, kann ich auch nur rausfinden, wenn ich in die Doku schaue... Bind war glaube ich für das, was bei Homematic "peering" heißt, also "Gruppenbildung" zwischen zwei Devices?...

Der ConBee II sollte potent genug sein für das bißchen... Firmware ist auf dem letzten Stand? (Anfang Dez. 2020) (Und sorry für die Unterstellung, es wäre was anderes, falls ich das übersehen haben sollte).

"Unregelmäßig" muss nichts heißen, evtl. sind da Schwellenwerte für Abweichungen definiert, die mal schneller, mal langsamer "gerissen" werden. Kenne ich von meinen Temp/hum-Sensoren, das kann auch bis zu einer Stunde dauern, bis da mal wieder ein Wert kommt, wenn sich nichts wesentliches geändert hat (deconz pusht auch).

[Snocksman]

Ich habe jetzt gerade zigbee2mqtt nochmal komplett runter geschmissen und die Installation mit deConz durchgeführt und nun läuft alles. Das Thermostat funktioniert (auch die Uhrzeit wird nicht mehr zurückgesetzt) und die restlichen Devices schalten viel schneller als per zigbee2mqtt.    Als Template für das Thermostat habe ich hierbei C_01_Eurotronic... verwendet. Das ist zwar auch nicht perfekt und es fehlen noch ein paar Sachen, aber das Schalten funktioniert hier schonmal zuverlässig.

MQTT wäre mir zwar lieber gewesen, aber wenns so funktioniert, bleibe ich erstmal dabei. Danke aber auf jeden Fall für die geduldige Hilfe !!!

[Beta-User]

Hmm, irgendwie finde ich das jetzt schade .

Aber evtl. möchtest du die neu gewonnene Zeit jetzt dafür verwenden, mal ein paar Vorschläge für die huedevice.template zu erarbeiten... Da ist die Zeit irgendwie ziemlich stehen geblieben .

[TomLee]

Würde auf den "remove"-Kommand tippen. Aber frag' mich nicht, wie man den verwendet, ich hatte das damals nur nach den Kommandos abgebildet, die bei zigbee2mqtt in der damaligen Doku zu finden waren; bisher hat sich keiner beschwert...

Nur mal zur Bestätigung das die Doku damals dann korrekt interpretiert wurde:

Code Auswählen Erweitern

set MQTT2_zigbee_Bridge remove 0x00158d00028aedf7

Code Auswählen Erweitern

Dez 14 15:09:33 FHEMPIOS npm[585]: Zigbee2MQTT:info  2020-12-14 15:09:33: Removing '0x00158d00028aedf7'
Dez 14 15:09:33 FHEMPIOS npm[585]: Zigbee2MQTT:warn  2020-12-14 15:09:33: Device '0x00158d00028aedf7' left the network
Dez 14 15:09:33 FHEMPIOS npm[585]: Zigbee2MQTT:info  2020-12-14 15:09:33: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"left_network","meta":{"friendly_name":"0x00158d00028aedf7"},"type":"device_removed"}'
Dez 14 15:09:33 FHEMPIOS npm[585]: Zigbee2MQTT:info  2020-12-14 15:09:33: Successfully removed 0x00158d00028aedf7
Dez 14 15:09:33 FHEMPIOS npm[585]: Zigbee2MQTT:info  2020-12-14 15:09:33: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"0x00158d00028aedf7","type":"device_removed"}'

[dcboy]

Ich hab gerade wieder was gefunden, wurde heute ein neues Issue eröffnet wegen den seltsamen Werten in der Auflistung der Heizprofile:
https://github.com/Koenkk/zigbee2mqtt/issues/5298

Der Fehler scheint wohl in der aktuellen DEV behoben worden zu sein.

Auch der Fehler mit der Uhrzeit scheint per Firmwareupdate Geschichte zu sein, sollte sogar inzwischen per z2m funktionieren!
https://github.com/Koenkk/zigbee2mqtt/issues/3821#issuecomment-702825657
und die Erfolgsmeldung hier:
https://github.com/Koenkk/zigbee-OTA/commit/a3c4aad6ea0dc04b6afcbc92a2dc762cca9726e5
https://github.com/Koenkk/zigbee2mqtt/issues/3821#issuecomment-716237961

Vielleicht hilft's bei dir auch @Snocksman ?

[Beta-User]

  Schön, dass es weitergeht!

Mit Risiko (weekprofile-Maintainer) hatte ich Kontakt, werde ihm die Tage dann eine noch etwas geänderte Fassung des Moduls zukommen lassen, dann hätten wir schon mal die Basisintegration vorbereitet, um mit Topics zu arbeiten.

So, wie ich die Sache jetzt verstehe, kann man "nur" zwei Tages Profile senden, nämlich eines für Werktage und eines für WE-Tage. 5+2 => Sa,So sind WE-Tage, 6+1 => nur So ist WE, 7 => alle Tage gleich (vermutlich nach workday).
Werde dann mal versuchen, das entsprechend so umzusetzen, dass Montag und Sonntag die "Leit-Tage" sind, die dann in das zu versendende Profil umgesetzt werden. Fraglich wäre dann aber, wie man mit $we-Tagen umgeht. Vermutlich gibt es dazu eine Art Modus-Umschalter, durch denn dann "holiday" ist, allerdings findet sich dazu nichts in der Doku.
Mal sehen, Rom und so...

[Snocksman]

Was ich nicht ganz verstehe: Wenn das mit der Uhrzeit ein Firmwarethema des Thermostats ist... Warum tritt das Problem mit der deConz Lösung nicht auf...? 

Ich glaube ich teste das die Tage aber auch nochmal mit Zigbee2MQTT... Ich finde das jetzt irgendwie komisch, dass das ganze mit deConz so viel besser läuft. Das schalten der Zwischenstecker funktioniert viel schneller, das Thermostat funktioniert einwandfrei und auch der Helligkeitssensor liefert jetzt regelmäßig Werte.

Vielleicht war da ja mit meiner Zigbee2MQTT Installation irgendwas nicht 100%ig...

[dcboy]

ok, das ist in der Tat etwas seltsam. Vielleicht ist wirklich was an der Installation faul.

@Beta-User
wie werden sich eigentlich die von dir erstellten Templates nach dem 01.01.2021 verhalten? Koenkk hat ja eine neue API Struktur entwickelt, die wird ab der neuen Version am 01.01 auch eingesetzt
https://github.com/Koenkk/zigbee2mqtt/issues/4466
bzw. hier der genaue Post
https://github.com/Koenkk/zigbee2mqtt/issues/4466#issuecomment-742709335

[Beta-User]

Na ja, wenn ich das richtig interpretiere mit der API-Änderung, betrifft das nur eine Kleinigkeit an einem "getter"; update kommt mit der nächsten Version.

Da wird dann voraussichtlich auch das mit weekprofile gleich integriert sein, passenden Modulcode hatte ich vorhin auch Risiko geschicht und hoffe mal darauf, dass er Zeit findet, um sich das anzuschauen.

Wäre gut, wenn jemand das noch testen wollte, dazu die beiden Dateien einfach mit den richtigen Rechten (typ: fhem:dialout) ins Modulverzeichnis packen...

attrTemplate sähe dann so aus:

Code Auswählen Erweitern

name:zigbee2mqtt_thermostat_with_weekrofile
desc: stub of a version for <a href="https://zigbee.blakadder.com/Moes_HY368-ZB.html">Model HY368-ZB manufactured by Moes</a> via zigbee2mqtt <br>Not yet tested... <br>To contribute, participate in <a href="https://forum.fhem.de/index.php/topic,116535.0.html">Forum Thread</a>
filter:TYPE=MQTT2_DEVICE:FILTER=CID~zigbee.*
order:L_17a
par:BASE_TOPIC;base topic set in configuration.yaml of the zigbee2mqtt bridge;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,[\b]?([^/:]+)[/].+, ? $1 : undef }
par:DEV_ID;name of the device in the zigbee2mqtt bridge;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,[^/]+[/]([^/:]+).*, ? $1 : undef }
par:ICON;ICON as set, defaults to hm-cc-rt-dn;{ AttrVal("DEVICE","icon","hm-cc-rt-dn") }
farewell:template has been applied successfully. <br>NOTE: code has been downloaded from svn (contrib). <br>For use with weekprofile, additional configuration is needed!
attr DEVICE comment For use with weekprofile, additional configuration is needed
attr DEVICE icon ICON
attr DEVICE devicetopic BASE_TOPIC/DEV_ID
attr DEVICE userattr weekprofile
attr DEVICE readingList $\DEVICETOPIC:.* { my %h; my $temp = $EVENT; $temp =~ s/,?("(holidays|workdays)":.([^]]+))./$h{$2}=$3/ge; $EVENT =~ s/,?("(holidays|workdays)":.([^]]+)).//g; my $h2 = json2nameValue($EVENT,'',$JSONMAP); %h = (%h,%$h2); \%h }
attr DEVICE setList \
  desired-temp:slider,5.0,0.5,30.0,1 $\DEVICETOPIC/set {"current_heating_setpoint": $EVTPART1 }\
  btnLock:LOCK,UNLOCK $\DEVICETOPIC/set {"child_lock": "$EVTPART1"}\
  boost:noArg $\DEVICETOPIC/set {"preset": "boost"}\
  mode:schedule,manual,boost,complex,comfort,eco $\DEVICETOPIC/set {"preset": "$EVTPART1"}\
  weekprofile { FHEM::attrT_z2m_thermostat_Utils::z2t_send_weekprofile($NAME, $EVTPART1, $EVTPART2) }\
  x_send_set_payload:textField { my $payload = $EVENT;$payload =~ s/$EVTPART0 //; qq($\DEVICETOPIC/set $payload)}
attr DEVICE getList desired-temp:noArg desired-temp $\DEVICETOPIC/get {"current_heating_setpoint": ""}\
  measured-temp:noArg measured-temp $\DEVICETOPIC/get {"local_temperature": ""}\
  mode:noArg mode $\DEVICETOPIC/get {"preset": ""}
attr DEVICE periodicCmd measured-temp:55
attr DEVICE stateFormat btnLock\
Measured: measured-temp Battery: batteryPercent %
attr DEVICE devStateIcon LOCKED:secur_lock:btnLock+UNLOCK UNLOCKED:secur_open:btnLock+LOCK
attr DEVICE webCmd desired-temp
attr DEVICE widgetOverride desired-temp:knob,min:5,max:30,angleArc:180,width:40,height:40,fgColor:#FF9900,bgColor:#CCCCCC,step:0.5,lineCap:round,angleOffset:225
attr DEVICE jsonMap current_heating_setpoint:desired-temp local_temperature:measured-temp Battery:batteryPercent preset:mode
attr DEVICE setStateList on off
attr DEVICE model zigbee2mqtt_thermostat_with_weekrofile
set DEVICE attrTemplate speechcontrol_type_thermostat
deletereading -q DEVICE (?!associatedWith).*
setreading DEVICE attrTemplateVersion 20201215

Der Code macht jetzt aus weekprofile-"Mon" "workdays" und aus weekprofile-"Sun" "holidays" (wenn "week" nicht "7" ist, sonst wird nur "wordkdays" gesendet), alles andere wird ignoriert, und ob die Zeiten so dann sinnvoll übersetzt sind, kann ich nicht sagen.

Testen kann man auch ohne direkte weekprofile-Unterstützung, dann sind der Name des weekprofile-Devices und <topic>:<entity> als Argumente zu verwenden, also z.b.

Code Auswählen Erweitern


set MQTT2_zigbee_0xbc33acfffe45850a weekprofile wp_test default:zigbeetestoder

Code Auswählen Erweitern

set MQTT2_zigbee_0xbc33acfffe45850a weekprofile wp_test test:zigbeetest

("zigbeetest" ist der Name des Thermostaten im weekprofile-Device "wp_test"; das ist aber nur dann relevant, wenn man diesen Namen dann im Attribut "weekprofile" gesetzt hat; darüber identifiziert weekprofile dann (später) seine "Clients".

Falls ihr noch nicht mit weekprofile gearbeitet haben solltet, ist das ggf. alles etwas verwirrend. Bin da zwar auch noch nicht vertieft drin, aber eine erste Orientierung kann ich vermutlich notfalls versuchen zu vermitteln...

[Beta-User]

Kurze Info: Risiko hat die Version mit MQTT2_DEVICE-Unterstützung vorhin dankenswerter Weise eingecheckt, und auch die attrTemplate-Änderung samt myUtils ist seit kurzem im svn und kommt dann mit dem morgigen update.
Irgendwann ziehe ich dann noch die commandref dazu nach, ist vermutlich erklärungsbedürftig, der perl-Code an der Stelle (v.a. auch, was die Voraussetzungen angeht, die erfüllt sein müssen).

Ob es glücklich ist, dass bei "week = "7" nur "workdays" versendet wird, werden wir sehen, es ging zunächst auch darum, die Möglichkeiten zu zeigen .

feedback wäre willkommen (falls jemand dann schon auf der letzten Version von z2m ist).

[Snocksman]

Ich setze mir morgen mal nen zweiten Raspi mit zigbee2mqtt zum testen auf... Dann zerbastele ich mir nicht ständig meinen FHEM Raspi (da ist die Frau dann irgendwann auch genervt...    ) und ich kann leichter zwischen deconz und zigbee2mqtt switchen.

[dcboy]

Ich habe bisher noch gar nicht mit den weekprofiles gearbeitet, mein "Produktiv-FHEM" steuert eigentlich bisher nur Licht und loggt etwas Stromverbrauch. Die ganzen Spielereien wie jetzt mit den Thermostaten, Telegram Bot usw. betreibe ich auf einem Test-PI, da kann ich problemlos ausprobieren. Ich bin bisher eher so derjenige, der sich nach Tutorials alles zusammenbastelt, Hauptsache danach funktionierts

Zwischenzeitlich wurde auch die Infoseite des Thermostats überarbeitet, jetzt kann man auch die Profile bearbeiten und die Comfort und Eco Temperatur, sowie die Boostfunktion und -zeit einstellen:

https://github.com/groenmarsmannetje/zigbee2mqtt.io/commit/ff407757a98c021f71544d06e65048a8de0602e4

Am Wochenende werd ich mir mal das mit den weekprofiles anschauen