Kommunikationsproblem FHEM - zigbee2mqtt

[Müller]

Hallo,

ich habe ein Kommunikationsproblem zu z2m:
Bei einen ubisys H1 Thermostat bekomme ich folgende Fehlermeldung in z2m:

Publish set ´occupied_heating_setpointto "device name" failed:Error: ´occupied_heating_setpoint is not a number, got string (14.0)

Diesen Fehler bekomme ich auf einer Linux Installation.
Auf einer anderen Installation (anderes Gebäude) mit einen Raspberry, läuft dies ohne Probleme.
Ein Thermostat eines anderen Herstellers funktioniert mit beiden Rechnern.

Hat jemand eine Idee, was da schief läuft ?

Danke & Gruß

RAW von der funktionierenden FHEM Instanz:

Code Auswählen Erweitern

defmod MQTT2_zigbee_0x001fee000000999b MQTT2_DEVICE zigbee_0x001fee000000999b
attr MQTT2_zigbee_0x001fee000000999b devStateIcon LOCKED:secur_lock:btnLock+UNLOCK UNLOCKED:secur_open:btnLock+LOCK
attr MQTT2_zigbee_0x001fee000000999b devicetopic zigbee2mqtt/0x001fee000000999b
attr MQTT2_zigbee_0x001fee000000999b icon temp_control
attr MQTT2_zigbee_0x001fee000000999b jsonMap occupied_heating_setpoint:desired-temp local_temperature:temperature Battery:batteryPercent system_mode:mode voltage:batterymV
attr MQTT2_zigbee_0x001fee000000999b model zigbee2mqtt_thermostat_without_weekrofile
attr MQTT2_zigbee_0x001fee000000999b readingList $DEVICETOPIC:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr MQTT2_zigbee_0x001fee000000999b room MQTT2_DEVICE
attr MQTT2_zigbee_0x001fee000000999b setList desired-temp:slider,5.0,0.5,30.0,1 $DEVICETOPIC/set {"occupied_heating_setpoint": "$EVTPART1"}\
  btnLock:LOCK,UNLOCK $DEVICETOPIC/set {"child_lock": "$EVTPART1"}\
  mode:heat,auto,off $DEVICETOPIC/set {"system_mode": "$EVTPART1"}\
  away:ON,OFF $DEVICETOPIC/set {"away_mode": "$EVTPART1"}\
  window_detection:ON,OFF,TOOGLE $DEVICETOPIC/set {"window_detection": "$EVTPART1"}
attr MQTT2_zigbee_0x001fee000000999b stateFormat btnLock\
Measured: temperature Battery: batteryPercent %
attr MQTT2_zigbee_0x001fee000000999b userReadings batteryState:battery_low.* {ReadingsVal($name,'battery_low','false') eq 'false'?'ok':'low'}, batteryVoltage:batterymV.* {ReadingsNum($name,'batterymV',0)/1000}
attr MQTT2_zigbee_0x001fee000000999b webCmd desired-temp

raw der nicht funktionierenden FHEM Variante:

Code Auswählen Erweitern

defmod MQTT2_zigbee_0x001fee000000999b MQTT2_DEVICE zigbee_0x001fee000000999b
attr MQTT2_zigbee_0x001fee000000999b devStateIcon LOCKED:secur_lock:btnLock+UNLOCK UNLOCKED:secur_open:btnLock+LOCK
attr MQTT2_zigbee_0x001fee000000999b devicetopic zigbee2mqtt/0x001fee000000999b
attr MQTT2_zigbee_0x001fee000000999b icon temp_control
attr MQTT2_zigbee_0x001fee000000999b jsonMap occupied_heating_setpoint:desired-temp local_temperature:temperature Battery:batteryPercent system_mode:mode voltage:batterymV
attr MQTT2_zigbee_0x001fee000000999b model zigbee2mqtt_thermostat_without_weekrofile
attr MQTT2_zigbee_0x001fee000000999b readingList $DEVICETOPIC:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr MQTT2_zigbee_0x001fee000000999b room MQTT2_DEVICE
attr MQTT2_zigbee_0x001fee000000999b setList desired-temp:slider,5.0,0.5,30.0,1 $DEVICETOPIC/set {"occupied_heating_setpoint": "$EVTPART1"}\
  btnLock:LOCK,UNLOCK $DEVICETOPIC/set {"child_lock": "$EVTPART1"}\
  mode:heat,auto,off $DEVICETOPIC/set {"system_mode": "$EVTPART1"}\
  away:ON,OFF $DEVICETOPIC/set {"away_mode": "$EVTPART1"}\
  window_detection:ON,OFF,TOOGLE $DEVICETOPIC/set {"window_detection": "$EVTPART1"}
attr MQTT2_zigbee_0x001fee000000999b stateFormat btnLock\
Measured: temperature Battery: batteryPercent %
attr MQTT2_zigbee_0x001fee000000999b userReadings batteryState:battery_low.* {ReadingsVal($name,'battery_low','false') eq 'false'?'ok':'low'}, batteryVoltage:batterymV.* {ReadingsNum($name,'batterymV',0)/1000}
attr MQTT2_zigbee_0x001fee000000999b webCmd desired-temp


[Beta-User]

Ist das die setList aus https://forum.fhem.de/index.php?msg=1309893? Oder eine andere (vermutlich)?

Hintergrund: in den älteren attrTemplate sind teils noch Quotes um Zahlen, und das führt dann (neuerdings) zu dieser Art Fehlermeldungen bei z2m.

Lösung (falls es ein anderes Device ist): Quotes um Zahlenwerte entfernen

[Müller]

ja das ist dieses Thermostat (auf dem Raspberry, wo es problemlos läuft)

[Müller]

Quotes in Fhem oder z2m?
wenn ich die raw definition von einen auf das andere System übertrage, hätte dies Aussicht auf Erfolg?

[Beta-User]

Quotes in Fhem oder z2m?

Die "Quotes" kommen aus der setList im "anderen System" (=>FHEM). Vergleiche "funktionierend" mit "nicht funktionierend", dann solltest du den Unterschied sehen.

wenn ich die raw definition von einen auf das andere System übertrage, hätte dies Aussicht auf Erfolg?

Wie soll man diese Frage beantworten? Vielleicht... Kommt auf die Details an...
Besser wäre es, den Hinweisen auf die Fehlerursache zu folgen und zu verstehen, wo der konkrete Unterschied liegt. "Hilfe zur Selbsthilfe" .

[Müller]

Hallo,
kann mir jemand einen Tip geben wo ich die Qoutes in zigbee2mqtt finde und wie man diese verändern kann ?

DANKE

[betateilchen]

Dann hole ich mal Popcorn und beobachte weiter, wie hier aneinander vorbeigeredet wird.
Das könnte noch lustig werden

kann mir jemand einen Tip geben wo ich die Qoutes in zigbee2mqtt finde

Ich tippe mal auf den Inhalt des Attributs "setList" im nicht funktionierenden device. Schau doch da mal im Umfeld von "occupied_heating_setpoint", das muss ja da irgendwo stehen.

Deshalb arbeite ich nicht mit templates. Wenn man ein device selbst anlegt, muss man dabei mitdenken und verstehen, was man tut...

[Beta-User]

Deshalb arbeite ich nicht mit templates. Wenn man ein device selbst anlegt, muss man dabei mitdenken und verstehen, was man tut...

Es ist auch gut und richtig, dass es Leute gibt, die auch keine fremden Perl-libs nutzen, ihre MCU's selber "from the scratch" programmieren, ...

Die meisten "Gelegenheits-Nutzer" tun sich nach meiner bisherigen Erfahrung leichter damit, eine (ggf. schlechte) Vorlage zu nehmen und ggf. daran Verbesserungen vorzunehmen oder anhand von Vorlagen neues zu konfigurieren.

PS: Es ist durchaus erlaubt, bei "schlechtem Code" (wie diesem Zahlen-Ding in JSON) direkt darauf hinzuweisen, dass es eine spec dafür gibt, die es anders vorsieht, wenn man als erfahrener User direkt sieht, dass da was schräg ist (selbst wenn es funktioniert)...

[betateilchen]

Die meisten "Gelegenheits-Nutzer" tun sich ... leichter damit, eine (ggf. schlechte) Vorlage zu nehmen und ggf. daran Verbesserungen vorzunehmen

Genau DAS wage ich zu bezweifeln. Zumindest, wenn ich mir die vielen gescheiterten Anpassungsversuche hier im Forum anschaue, die den einen oder anderen Anwender völlig zur Verzweiflung treiben.

"Vorlagen" bevormunden eben den Anwender, indem sie ihm erstmal den Gedanken eines Anderen (des Vorlagenerstellers) aufzwingen, ohne dass dem Anwender wirklich erklärt wird, was man sich bei der Vorlage gedacht hat.

Für meine Szenarien gibt es nicht ein einziges template, das meine Anforderungen erfüllen würde.
Deshalb bin ich einfach schneller am Ziel, wenn ich mir die readingList und setList selbst baue.

PS: Es ist durchaus erlaubt, bei "schlechtem Code" (wie diesem Zahlen-Ding in JSON) direkt darauf hinzuweisen, dass es eine spec dafür gibt, die es anders vorsieht,

Das habe ich schon ein paarmal gemacht (gerade bei den numerischen und boolschen Werten), oft wurden die Hinweise aber schlichtweg ignoriert.

[Beta-User]

PS: Es ist durchaus erlaubt, bei "schlechtem Code" (wie diesem Zahlen-Ding in JSON) direkt darauf hinzuweisen, dass es eine spec dafür gibt, die es anders vorsieht,

Das habe ich schon ein paarmal gemacht (gerade bei den numerischen und boolschen Werten), oft wurden die Hinweise aber schlichtweg ignoriert.

Hmm, will nicht ausschließen, dass mir was in die Richtung durchgegangen ist, meine aber, relativ zeitnah zum ersten Auftreten des Problems bei zigbee2mqtt alle betreffenden attrTemplates geändert zu haben. Kann weiter sein, dass das nicht alles war und/oder ich da was übersehen habe. Also falls du dafür ein Beispiel für konkrete Kritik hättest, würde es mir leichter fallen zu glauben, ich hätte da was ignoriert.
"Auf Vorrat" schaue ich mir das ganze file aber auch nicht an, denn das Risiko besteht durchaus, dass dadurch (neue) Fehler oder Probleme entstehen.

Genau DAS wage ich zu bezweifeln. Zumindest, wenn ich mir die vielen gescheiterten Anpassungsversuche hier im Forum anschaue, die den einen oder anderen Anwender völlig zur Verzweiflung treiben.

Na ja, es gibt auch user, die einfache notify nicht hinbekommen, und es gibt einige Beispiele, bei denen jemand mit wenig Vorerfahrung brauchbares geliefert hat...

"Vorlagen" bevormunden eben den Anwender, indem sie ihm erstmal den Gedanken eines Anderen (des Vorlagenerstellers) aufzwingen, ohne dass dem Anwender wirklich erklärt wird, was man sich bei der Vorlage gedacht hat.

Für die, die es interessiert, gibt es in der Regel einen Quellennachweis (direkt in der file). Ansonsten ist es eine Sammlung, bei der - zumindest in Teilen - eine gewisse Richtung eingehalten ist, aber eben so, wie die (aktiven...) beteiligten User das haben wollten und für gut befunden haben. Die generelle Richtung kann man im "Workshop" nachlesen, einiges ist auch im Wiki dargestellt.

Ist m.E. besser wie das "alte Gemähre", das bei den früheren MQTT_DEVICE-Konfigurationen häufig vorzufinden war. Da wurde auch "wild zusammengeklaut", und überhaupt funktionaler Code war (jedenfalls nach meinem Bauchgefühl) eher Glückssache. In der Vor-attrTemplate-Zeit von MQTT2_DEVICE war es kaum besser...

Für meine Szenarien gibt es nicht ein einziges template, das meine Anforderungen erfüllen würde.
Deshalb bin ich einfach schneller am Ziel, wenn ich mir die readingList und setList selbst baue.

Glaub dir durchaus, dass (auch) du schneller mit eigenen Konfigurationen bist. Ob du "alle" eventuell passenden attrTemplate durchgesehen hast, kann ich nicht beurteilen, zumal du das feature ja deaktiviert hast .

[Müller]

Hallo,
ich habe heute ein update von FHEM gemacht.
anschließend habe ich das template "zigbee2mqtt_thermostat_without-Week
neu angewendet.
Habe dann noch rumgewurschtelt (2-3x Device gelöscht und wieder hinzugefügt) jetzt scheint es zu gehen

(Mein Verständnis vom dem Problem und seiner Lösung ist nur wenig über Null))