Shelly‘s über mqtt update

[rudolfkoenig]

Habt ihr evtl. nach dem update FHEM nicht neu gestartet?


Habe nochmal mit folgendem fhem.cfg

Code Auswählen Erweitern

attr global logfile -
attr global modpath .
attr global statefile log/fhem.test.save

define w FHEMWEB 8083
define t telnet 7072

define m2s MQTT2_SERVER 1883
define ac autocreate
define announceDev MQTT2_DEVICE
attr announceDev readingList shellies/announce:.* { json2nameValue($EVENT, $CID."_") }
und dem obigen mosquitto_pub getestet, und die Readings werden fuer announceDev erzeugt, wie oben gezeigt.

[Beta-User]

Doch, klar (sicherheitshalber eben nochmal wiederholt, gleicher Befund)...

Das war vorhin auch ein Komplettupdate, nix selektives.

(Strawberry-) Perl ist lt. fheminfo 5.28.1@MSWIN32

[carlos]

Ebenso bei mir, update fhem restart.
Perl auch bei mir 5.28.1

Nach einem

Code Auswählen Erweitern

define announceDev MQTT2_DEVICE
und

Code Auswählen Erweitern

attr announceDev readingList shellies/announce:.* { json2nameValue($EVENT, $CID."_") }
kommt diesen Fehler.

[rudolfkoenig]

Gibt es in eurem 10_MQTT2_DEVICE.pm folgende Zeile?

Code Auswählen Erweitern

                 "%CID"=>$cid, "%JSONMAP","\$defs{$dev}{JSONMAP}"));
Habs auch mit 5.28.1 jetzt nachgetestet, kein Unterschied. Ratlos.

[Beta-User]

Hmmm, also: Ich habe das nicht über ein Publish gemacht, sondern einfach - wie üblich - versucht, das Attribut anzulegen. Das klappt wie beschrieben nicht, kann sein, dass die Variable im Rahmen des autocreate-Vorgangs verfügbar ist, aber auf manuellem Weg nicht. Evtl. müßte das %CID in dem perlSyntaxCheck ab Zeile 411 noch ergänzt werden?

[rudolfkoenig]

Peinlich
Habe eine neue Version eingecheckt.

[Beta-User]

 

Ein allg. update-Device könnte dann so aussehen:

Code Auswählen Erweitern


defmod announceDev MQTT2_DEVICE
attr announceDev readingList shellies/announce:.* { json2nameValue($EVENT, $CID."_") }
attr announceDev setList update_device:textField {"shellies/$EVTPART1/command update_fw"}
Einzugeben wäre das, was jeweils unter dem gleichen Präfix als id übermittelt wurde.

[carlos]

Top, funktioniert:

In der api docu steht folgendes:

Code Auswählen Erweitern

Common MQTT commands

Shellies support a set of commands published on shellies/command or shellies/<shellymodel>-<deviceid>/command to address an individual device:

    announce will trigger an announce packet by every Shelly connected to the broker on shellies/announce
    update will cause all Shellies to publish their state
    update_fw to perform a firmware update when one is available.


man könnte also sich folgendes setlist attribut zusammenstellen

Code Auswählen Erweitern


attr announceDev setList update_fw_all:noArg {"shellies/command update_fw"}\
                                         update_fw_device:textField {"shellies/$EVTPART1/command update_fw"}\
                                         update_all:noArg {"shellies/command update"}\
                                         update_device:textField {"shellies/$EVTPART1/command update"}\
                                         announce:noArg {"shellies/command announce"}
                                         

[Beta-User]

...das ergäbe dann folgendes template:

Code Auswählen Erweitern


name:shelly_announces
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*shellies.*
order:A_101
desc:Allows central administration of all shelly firmware updates
attr DEVICE setList\
  update_fw_all:noArg {"shellies/command update_fw"}\
  update_fw_device:textField {"shellies/$EVTPART1/command update_fw"}\
  request_update_all:noArg {"shellies/command update"}\
  request_update_device:textField {"shellies/$EVTPART1/command update"}\
  request_announces:noArg {"shellies/command announce"}
attr DEVICE readingList shellies/announce:.* { json2nameValue($EVENT, $CID."_") }
Wäre nett, wenn das noch jemand testen könnte, der die Teile hat, dann checke ich das bei Gelegenheit ein... .

[tomleitner]

Hallo,
Ist das schon eingecheckt? Ich kriege folgendes (raw def):

Code Auswählen Erweitern

defmod ShellyDevList MQTT2_DEVICE
attr ShellyDevList IODev MQTT_Client
attr ShellyDevList readingList shellies/announce:.* {  json2nameValue($EVENT, $CID."_")  }
attr ShellyDevList room MQTT

setstate ShellyDevList 2019-11-26 19:24:26 MQTT_Client_fw_ver 20190821-095211/v1.5.2@4148d2b7
setstate ShellyDevList 2019-11-26 19:24:26 MQTT_Client_id shellyht-58EA7E
setstate ShellyDevList 2019-11-26 19:24:26 MQTT_Client_ip 10.10.1.13
setstate ShellyDevList 2019-11-26 19:24:26 MQTT_Client_mac CC50E358EA7E
setstate ShellyDevList 2019-11-26 19:24:26 MQTT_Client_new_fw false


d.h. die readings werden alle überschrieben und es werden keine separaten readings pro Shelly device angelegt?

Was ist da falsch?  Hab natürlich ein "update" gemacht ...

Danke.

Tom

[Beta-User]

Hallo,
Ist das schon eingecheckt?

Ggf. update und danach mal

Code Auswählen Erweitern

set ShellyDevList attrTemplate ?ausführen sollte die Frage auf einfache Weise beantworten....

[tomleitner]

Ggf. update und danach mal

Code Auswählen Erweitern

set ShellyDevList attrTemplate ?ausführen sollte die Frage auf einfache Weise beantworten....

Danke ... habe ich nun nochmal gemacht. Ich habe das "shelly_announces" template gefunden und angewendet. Resultat ist immer noch dasselbe:

Code Auswählen Erweitern

defmod ShellyDevList MQTT2_DEVICE
attr ShellyDevList IODev MQTT_Client
attr ShellyDevList readingList shellies/announce:.* { json2nameValue($EVENT, $CID."_") }
attr ShellyDevList room MQTT
attr ShellyDevList setList update_fw_all:noArg {"shellies/command update_fw"}\
  update_fw_device:textField {"shellies/$EVTPART1/command update_fw"}\
  request_update_all:noArg {"shellies/command update"}\
  request_update_device:textField {"shellies/$EVTPART1/command update"}\
  request_announces:noArg {"shellies/command announce"}

setstate ShellyDevList request_announces
setstate ShellyDevList 2019-11-27 10:35:58 MQTT_Client_fw_ver 20190821-095050/v1.5.2@4148d2b7
setstate ShellyDevList 2019-11-27 10:35:58 MQTT_Client_id shelly4pro-4BC4F4
setstate ShellyDevList 2019-11-27 10:35:58 MQTT_Client_ip 10.10.1.101
setstate ShellyDevList 2019-11-27 10:35:58 MQTT_Client_mac D436394BC4F4
setstate ShellyDevList 2019-11-27 10:35:58 MQTT_Client_new_fw false
setstate ShellyDevList 2019-11-27 10:35:57 state request_announces

... oder ist meine Erwartungshaltung falsch das ich damit alle Shelly Geräte die sich über shellies/announce melden in separaten readings bekomme? Bekomme ich nämlich nicht!

Danke // Tom

[Beta-User]

OK, jetzt wird das klarer.

Deine Erwartungshaltung ist grundsätzlich richtig, aber du hast als IO einen MQTT2_CLIENT laufen, es jedoch kein Device MQTT2_CLIENT_general_bridge vorhanden?

(Die CID ist dann nämlich nur die vom CLIENT für alle eingehenden Nachrichten... Das wird erst dann (in Teilen) anders, wenn man die Nachrichten mit einem speziellen Device "vorverarbeitet".)

[tomleitner]

OK, jetzt wird das klarer.

Deine Erwartungshaltung ist grundsätzlich richtig, aber du hast als IO einen MQTT2_CLIENT laufen, es jedoch kein Device MQTT2_CLIENT_general_bridge vorhanden?

(Die CID ist dann nämlich nur die vom CLIENT für alle eingehenden Nachrichten... Das wird erst dann (in Teilen) anders, wenn man die Nachrichten mit einem speziellen Device "vorverarbeitet".)

Ok, habe ein weiteres MQTT2_DEVICE mit AttrTemplate MQTT2_CLIENT_general_bridge angelegt. Komischerweise hat er mit dann noch ein MQTT2_DEVICE namens mosquitto angelegt. Egal: Hier das mosquitto device:

Code Auswählen Erweitern

defmod mosquitto MQTT2_DEVICE mosquitto
attr mosquitto IODev MQTT_Client
attr mosquitto autocreate 1
attr mosquitto bridgeRegexp (tele|cmnd)[/]([^/]+)[/].*:.* "$2"\
  shellies[/]([^/]+)[/].*:.* "$1"\
  (ESPClient_[^/]+)[/].*:.* "$1"\
  valetudo[/]([^/]+)[/].*:.* "$1"\
  [^/]+[/](ems-esp[^/]+)[/].*:.* "$1"\
  wallpanel[/]([^/]+)[/].*:.* "$1"\
  (wled)[/]([^/]+)[/].*::.* "$1_$2"\
  (go-eCharger)[/]([^/]+)[/].*::.* "go_eCharger_$2"
attr mosquitto comment Do not use very open bridgeRegexp expressions! This might lead to irritating results...
attr mosquitto model MQTT2_CLIENT_general_bridge
attr mosquitto room MQTT
attr mosquitto setStateList on off

setstate mosquitto 2019-11-27 11:06:18 associatedWith MQTT_Client_Generic_Bridge


Das IODev des mosqitto hab ich auf meinen MQTT2_CLIENT gelegt. Sodann das mosquitto als IODev für das ShellyDevList device genommen und: ..... Gleiches Problem

Was mach ich falsch?  Wäre übrigens gut wenn das in der Beschreibung vom AttrTemplate des shellies_announces templates etwas beschrieben werden würde was hier erwartet wird ??

Danke // Tom

[Beta-User]

Also: Das "mosquitto"-Teil IST die MQTT2_CLIENT_general_bridge . (Müßte doch in der Beschreibung stehen, dass ein neues Device angelegt wird). Da du das "Basisdevice" händisch angelegt hattest, war vermutlich noch kein IO angegeben, dann wird eben "mosquitto" als Name dafür verwendet. Der ist aber im Prinzip willkürlich...

Die Funktionsweise des ganzen ist evtl. nach der Lektüre von dem hier https://wiki.fhem.de/wiki/MQTT2_CLIENT einfacher; dachte erst, du hast jetzt das Problem, dass die Reihenfolge des Anlegens nicht paßt und daher das "Sortierdevice" gar nicht mehr greift, weil es schon entsprechende Einträge gibt.

Nach einigem Nachdenken ist es aber wohl so, dass dieses template (genauer: der Rückgriff auf die CID) nur in Kombination mit dem MQTT2_SERVER funktioniert... Man müßte das ganze in die Richtung umbauen, wie es jetzt z.B. bei tasmota_ir angedeutet ist, und $CID (genauer: dann $1) via Regex ermitteln und über "gefunden/nicht gefunden" die auszuführende Variante von json2nameValue() bestimmen:

Code Auswählen Erweitern

TELETOPIC/RESULT:.* { $EVENT =~ m,..IrReceived....Protocol...([A-Za-z0-9]+)...Bits..([\d]+)..Data...([A-Za-z0-9]+)..., ? {"$1_$2"=>$3} : json2nameValue($EVENT) }

Reicht das als Anregung?