Passende ReadingList für Z-Wave JS UI (ehemals Z-WaveJS2MQTT)

[rubinho]

Ich versuche gerade vernünftige Readings für meine Z-Wave Devices zu bekommen.

Folgende Userreadings wurden bisher automatisch erstellt...

Code Auswählen Erweitern


zwave/nodeID_3/lastActive:.* { json2nameValue($EVENT) }
zwave/nodeID_3/48/0/Any:.* { json2nameValue($EVENT) }
zwave/nodeID_3/49/0/Illuminance:.* { json2nameValue($EVENT) }
zwave/nodeID_3/status:.* { json2nameValue($EVENT) }
zwave/nodeID_3/128/0/level:.* { json2nameValue($EVENT) }
zwave/nodeID_3/128/0/isLow:.* { json2nameValue($EVENT) }
zwave/nodeID_3/49/0/Humidity:.* { json2nameValue($EVENT) }
zwave/nodeID_3/49/0/Air_temperature:.* { json2nameValue($EVENT) }
zwave/nodeID_3/32/0/currentValue:.* { json2nameValue($EVENT) }


Als Output kommen solche Meldungen an...

Code Auswählen Erweitern

{"time":1677882432938,"value":4}

Bei den Aktuellen Userreadings werden somit alle Werte entweder als Reading time, oder value abgelegt. Egal welcher Sensor.

Den Timestamp benötige ich im Prinzip nicht. Ich benötige lediglich den Wert nach value, mit ensprechend definierten Reading (Temperatur, Humidity usw.)

Bisher habe ich folgendes ausprobiert...

Code Auswählen Erweitern

zwave/nodeID_3/49/0/Air_temperature:.* { json2nameValue($EVENT,"Temp_") }

Damit werden zwei Readings angelegt. Temp_time und Temp_value.
Das würde zwar gehen, ist aber nicht schön, da ich dann für jeden Sensor einen Timestamp mitbekomme den ich eh nicht richtig interpretieren kann.

Hat jemand einen Tip für mich?

Vorab Danke

VG
Rubinho


#### Update #####
Mist ich war zu schnell.

Ich konnte die Ausgabe in Z-Wave JS UI vereinfachen.
Nun bekomme ich richtige Werte.

Sorry

[Beta-User]

"Userreading" ist die falsche Begrifflichkeit, es geht offenbar um readingList. (mal wieder nur ein Auszug, und nicht die eigentlich angesagte "volle Info"...)

Kurzfassung: Gib es auf mit Z-Wave2mqtt und verwende eine "vernünftige" ZWave-Implementierung. Wir hatten das Thema vor längerem schon mal (soweit ich mich entsinne mit krikan), und es wäre unglaublich aufwändig, die auf diese Weise ankommenden Infos sinnvoll zu konsolidieren.

(OT: Es wäre interessant zu wissen, wie der Autor dieses Tools diese Struktur auswertet...)

[rubinho]

Ich bin schon ein großes Stück weiter.

Folgendes habe ich bisher in den MQTT Parameters auf Z-Wave JS UI eingestellt.

Prefix: zwave
Topic Type: Named topics (Default ist ValueID topics)
Payload Type: Just Value (Default ist Jsom Time Value, weitere Möglichkeit wäre noch "Entire Z-Wave value Object")

Mit den oben genannten Einstellungen bekomme ich folgende Readinglist erzeugt.....

Code Auswählen Erweitern

zwave/MultiSensor_1/lastActive:.* lastActive
zwave/MultiSensor_1/sensor_multilevel/endpoint_0/Illuminance:.* Illuminance
zwave/MultiSensor_1/sensor_multilevel/endpoint_0/Air_temperature:.* Air_temperature
zwave/MultiSensor_1/sensor_multilevel/endpoint_0/Humidity:.* Humidity
zwave/MultiSensor_1/configuration/endpoint_0/Wake_Device_for_10_minutes_After_Power_On:.* Wake_Device_for_10_minutes_After_Power_On
zwave/MultiSensor_1/configuration/endpoint_0/Trigger_Off_Period:.* Trigger_Off_Period
zwave/MultiSensor_1/configuration/endpoint_0/Motion_Sensor:.* Motion_Sensor
zwave/MultiSensor_1/configuration/endpoint_0/Motion_Sensor_Report_Type_to_Send:.* Motion_Sensor_Report_Type_to_Send
zwave/MultiSensor_1/configuration/endpoint_0/Automatic_Report_Group_1_-_Battery/1:.* Automatic_Report_Group_1_-_Battery_1
zwave/MultiSensor_1/configuration/endpoint_0/Automatic_Report_Group_1_-_Temperature/32:.* Automatic_Report_Group_1_-_Temperature_32
zwave/MultiSensor_1/configuration/endpoint_0/Automatic_Report_Group_1_-_Humidity/64:.* Automatic_Report_Group_1_-_Humidity_64
zwave/MultiSensor_1/configuration/endpoint_0/Automatic_Report_Group_1_-_Luminance/128:.* Automatic_Report_Group_1_-_Luminance_128
zwave/MultiSensor_1/configuration/endpoint_0/Automatic_Report_Group_2_-_Battery/1:.* Automatic_Report_Group_2_-_Battery_1
zwave/MultiSensor_1/configuration/endpoint_0/Automatic_Report_Group_2_-_Temperature/32:.* Automatic_Report_Group_2_-_Temperature_32
zwave/MultiSensor_1/configuration/endpoint_0/Automatic_Report_Group_2_-_Humidity/64:.* Automatic_Report_Group_2_-_Humidity_64
zwave/MultiSensor_1/configuration/endpoint_0/Automatic_Report_Group_2_-_Luminance/128:.* Automatic_Report_Group_2_-_Luminance_128
zwave/MultiSensor_1/configuration/endpoint_0/Automatic_Report_Group_3_-_Battery/1:.* Automatic_Report_Group_3_-_Battery_1
zwave/MultiSensor_1/configuration/endpoint_0/Automatic_Report_Group_3_-_Temperature/32:.* Automatic_Report_Group_3_-_Temperature_32
zwave/MultiSensor_1/configuration/endpoint_0/Automatic_Report_Group_3_-_Humidity/64:.* Automatic_Report_Group_3_-_Humidity_64
zwave/MultiSensor_1/configuration/endpoint_0/Automatic_Report_Group_3_-_Luminance/128:.* Automatic_Report_Group_3_-_Luminance_128
zwave/MultiSensor_1/configuration/endpoint_0/Automatic_Reporting_Interval_Group_1:.* Automatic_Reporting_Interval_Group_1
zwave/MultiSensor_1/configuration/endpoint_0/Automatic_Reporting_Interval_Group_2:.* Automatic_Reporting_Interval_Group_2
zwave/MultiSensor_1/configuration/endpoint_0/Automatic_Reporting_Interval_Group_3:.* Automatic_Reporting_Interval_Group_3

Die Readings sehen jedenfalls vielversprechend gut aus....

Code Auswählen Erweitern

setstate MQTT2_Zwave_MultiSensor_1 2023-03-04 09:53:57 Air_temperature 20.1
setstate MQTT2_Zwave_MultiSensor_1 2023-03-04 09:54:58 Automatic_Report_Group_1_-_Battery_1 0
setstate MQTT2_Zwave_MultiSensor_1 2023-03-04 09:54:58 Automatic_Report_Group_1_-_Humidity_64 0
setstate MQTT2_Zwave_MultiSensor_1 2023-03-04 09:54:58 Automatic_Report_Group_1_-_Luminance_128 0
setstate MQTT2_Zwave_MultiSensor_1 2023-03-04 09:54:58 Automatic_Report_Group_1_-_Temperature_32 0
setstate MQTT2_Zwave_MultiSensor_1 2023-03-04 09:54:58 Automatic_Report_Group_2_-_Battery_1 0
setstate MQTT2_Zwave_MultiSensor_1 2023-03-04 09:54:58 Automatic_Report_Group_2_-_Humidity_64 0
setstate MQTT2_Zwave_MultiSensor_1 2023-03-04 09:54:58 Automatic_Report_Group_2_-_Luminance_128 0
setstate MQTT2_Zwave_MultiSensor_1 2023-03-04 09:54:58 Automatic_Report_Group_2_-_Temperature_32 0
setstate MQTT2_Zwave_MultiSensor_1 2023-03-04 09:54:58 Automatic_Report_Group_3_-_Battery_1 0
setstate MQTT2_Zwave_MultiSensor_1 2023-03-04 09:54:58 Automatic_Report_Group_3_-_Humidity_64 0
setstate MQTT2_Zwave_MultiSensor_1 2023-03-04 09:54:58 Automatic_Report_Group_3_-_Luminance_128 0
setstate MQTT2_Zwave_MultiSensor_1 2023-03-04 09:54:58 Automatic_Report_Group_3_-_Temperature_32 0
setstate MQTT2_Zwave_MultiSensor_1 2023-03-04 09:54:58 Automatic_Reporting_Interval_Group_1 720
setstate MQTT2_Zwave_MultiSensor_1 2023-03-04 09:54:58 Automatic_Reporting_Interval_Group_2 720
setstate MQTT2_Zwave_MultiSensor_1 2023-03-04 09:54:58 Automatic_Reporting_Interval_Group_3 720
setstate MQTT2_Zwave_MultiSensor_1 2023-03-04 09:53:59 Humidity 23
setstate MQTT2_Zwave_MultiSensor_1 2023-03-04 09:53:55 IODev Fhem2MQTT
setstate MQTT2_Zwave_MultiSensor_1 2023-03-04 09:53:57 Illuminance 748
setstate MQTT2_Zwave_MultiSensor_1 2023-03-04 09:54:57 Motion_Sensor 1
setstate MQTT2_Zwave_MultiSensor_1 2023-03-04 09:54:57 Motion_Sensor_Report_Type_to_Send 1
setstate MQTT2_Zwave_MultiSensor_1 2023-03-04 09:54:56 Trigger_Off_Period 1
setstate MQTT2_Zwave_MultiSensor_1 2023-03-04 09:54:56 Wake_Device_for_10_minutes_After_Power_On 1
setstate MQTT2_Zwave_MultiSensor_1 2023-03-04 09:54:58 associatedWith MQTT2_Fhem2MQTT

Meine MQTT-Zwave Bridge habe ich zum Testen sehr eingeschränkt.

Code Auswählen Erweitern

bridgeRegexp: zwave/MultiSensor_1/.*:.* "Zwave_MultiSensor_1"

Keine Ahnung ob das Standard-Bridge-Template hier greifen würde. (Ich traue mich nicht, nach dem ich durch ne Fehlkonfiguration der Bridge mein Fhem quasi abgeschossen hatte)


Wie müsste die bridgeRegexp schreiben, dass ich nicht für jedes Z-Wave Device einen entsprechenden Eintrag machen muss?

@Beta-User
Wenn du irgenwas über die Ausgaben von Z-WaveJS2MQTT wissen willst, sag bescheid. Musst mir nur sagen welche Infos du benötigst und wie ich da ran komme

[rudolfkoenig]

bridgeRegexp erfindet ein ClientID aus dem Topic, anhand dessen die automatische Zuordnung zu einem Device stattfindet, wenn kein readingsList sich zustaendig fuehlt => mMn ist das hier der falsche Weg.

Soweit ich sehe, kann hier ein (neues/eigenes) attrTemplate weiterhelfen, indem man mit einer eigenen Funktion die Topics zu einem besseren Readingnamen umformatiert.

[Beta-User]

mMn ist das hier der falsche Weg.

Wieso bist du dieser Auffassung? Das sieht für mich _an dieser Stelle_ auch nicht wesentlich anders aus als bei anderen x2mqtt-Implementierungen: Es gibt einen Service, der gibt das Zentraldevice, und alles, was irgendwie einer darüber angesteuerten hardware zugeordnet werden kann (hier: 2. Teil des topic-trees) kommt jeweils in eine eigene M2D-Instanz.

Soweit ich sehe, kann hier ein (neues/eigenes) attrTemplate weiterhelfen, indem man mit einer eigenen Funktion die Topics zu einem besseren Readingnamen umformatiert.

Ich habe da noch keine Vorstellung, wie das aussehen sollte, weil man für sowas nach meinem möglicherweise zu begrenzten Verständnis auch vertiefte Kenntnisse darüber haben sollte, wie ZWave an sich "tickt".

Dass da irgendwelche Konfigurations-Bytes auf mehrere Topics verteilt werden (?), stimmt mich jedenfalls nicht optimistisch, dass das überhaupt mit überschaubarem Aufwand aufgearbeitet werden kann, zumal dann "allgemeine Hilfsmittel" wie die xml-Files nicht verfügbar sind. Ich kann und will das jedenfalls derzeit nicht leisten, es gibt mit der nativen Implementierung in FHEM mAn. eine deutlich einfachere Implementierung, die auch bessere debugging-Möglichkeiten bietet, wenn was nicht funktioniert.

@rubino: Tut mir leid, aber trotz der gewissen Verbesserung der Darstellung über die anderen Einstellungen bin ich in dieser Sache raus.

[rubinho]

@rubino: Tut mir leid, aber trotz der gewissen Verbesserung der Darstellung über die anderen Einstellungen bin ich in dieser Sache raus.

Alles Gut, ich nutze Z-Wave in den meisten Fallen für passive Sensoren (Temperatur, Bewegung) 
Für die paar Steckdosen die ich nutze, werde ich mir eine Lösung erarbeiten.

Trotzdem Danke für die Unterstützung.

Viele Grüße
Ruhinho

[rubinho]

Falls es keinen Stört, werde ich ein paar Erkenntnisse hier einpflegen.
Man muss ja das Rad nicht neu erfinden.

Ich habe mal ein Zwave Pluq über MQTT eingebunden.

hier die Parameter...

Code Auswählen Erweitern


readingList
zwave/Plug_05/lastActive:.* lastActive
zwave/Plug_05/switch_binary/endpoint_0/currentValue:.* { $EVENT eq "true" ? {"state"=>"on"} : {"state"=>"off"} }
zwave/Plug_05/switch_binary/endpoint_0/targetValue:.* targetValue
zwave/Plug_05/meter/endpoint_0/value/66561:.* Voltage
zwave/Plug_05/meter/endpoint_0/value/65537:.* Energy
zwave/Plug_05/meter/endpoint_0/value/66049:.* Power

setList   
off:noArg zwave/Plug_05/switch_binary/endpoint_0/targetValue/set false
on:noArg zwave/Plug_05/switch_binary/endpoint_0/targetValue/set  true
reset:noArg zwave/Plug_05/meter/endpoint_0/reset/set true

Das ist mit Sicherheit nicht Perfekt, aber für meine Bedürfnisse erstmal ausreichend.

[rudolfkoenig]

Wieso bist du dieser Auffassung?

Weil ich als Problem nicht die Verteilung der Daten an einzelne Geraete, sondern die Darstellung der Readings in diesen Geraeten verstanden habe.

Ansonten bin ich deiner Meinung: bis man ein mit dem ZWave Modul vergleichbare Funktionalitaet mit MQTT hinkriegt, muss man viel basteln. Ich will aber keinen vom Arbeit abhalten.

[rubinho]

Ich will aber keinen vom Arbeit abhalten.

Danke 

[Beta-User]

Danke 

Ich übrigens auch nicht...

Weil ich als Problem nicht die Verteilung der Daten an einzelne Geraete, sondern die Darstellung der Readings in diesen Geraeten verstanden habe.

Na ja, das Darstellungsthema ist sicher der größere Brocken, aber eine Vorsortierung dessen, was man schon "weiß", hilft uU. auch schon weiter.

Hier ist zusätzlich "unschön", dass es keine klare Trennung zwischen "set"- und Status-Topics zu geben scheint...

Ansonten bin ich deiner Meinung: bis man ein mit dem ZWave Modul vergleichbare Funktionalitaet mit MQTT hinkriegt, muss man viel basteln.

An dich als ZWave-Experten: Gehe ich recht in der Annahme, dass auch die hier im Topic stehenden Ziffern herstellerspezifisch sind und man nicht davon ausgehen kann, dass da irgendeine allgemeingültige Logik dahintersteht?

[rudolfkoenig]

Gehe ich recht in der Annahme, dass auch die hier im Topic stehenden Ziffern herstellerspezifisch sind und man nicht davon ausgehen kann, dass da irgendeine allgemeingültige Logik dahintersteht?

Diese Ziffern duerften spezifisch fuer die ZWave METER Klasse sein, vermutlich hat man das Telegramm nur teilweise dekodiert. Es enthaelt neben Typ noch Einheit, Anzahl der Nachkommastellen, Skalierung und Anzahl der Bytes. Siehe die Funktion ZWave_meterParse in FHEM/10_ZWave.pm. Oder die ZWave Klassendokumentation, das ist mW oeffentlich verfuegbar.

Geraetespezifisch ist nur die CONFIGURATION Klasse, das wird in den XML-Dateien (bzw. auf dem Beipackzettel) dokumentiert.