Hallo
Ich versuche schon einige Zeit meine Shellies (1 und 2) via mqtt upzudaten.
Leider komme ich auf keinen grünen Zweig damit.
Durch meine Versuche mit fw_update, update bzw announce ändert sich leider nichts und ich sehe auch keine neuen Informationen.
Kann mir da vielleicht jemand von euch einen codeschnippsel oder ander Hilfe geben?
Danke
Lies doch bitte die im Anfängerbereich angepinnten Beiträge und poste dann die erforderliche Info.
Habe grade keine Lust zu raten, ob du MQTT_DEVICE, MQTT2_DEVICE oder was eigengebautes verwendest und wie ggf. dein publish-Befehl aussieht, mit dem das update angestoßen werden soll.
@beta-user
ich schätze dein Wissen, und habe auch Achtung davor, nur raten brauchst du nicht!
In der Überschrift steht "mqtt" und nicht "mqtt2" und Shelly's, somit ist meiner Meinung nach klar um was es geht, falls nicht, Entschuldigung dafür.
Die Shellies sind mit MQTT_DEVICE in fhem eingebunden, weiters gibt es die commandos lt http://shelly-api-docs.shelly.cloud/#common-mqtt-commands
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.
mit welchen ich keinen Erfolg oder richtige Anwendung hatte, darum meine Bitte um Hilfe. Bisher habe ich nur für openhab scripte gefunden, da kenne ich mich leider Null aus.
Leider war der Überschrift nicht so genau zu entnehmen, dass "mqtt" hier "IO-bezogen" gemeint war ;) .
Zur Sache: in den templates zu mqtt2 findet sich folgendes:x_update:noArg shellies/DEVNAME/command update_fw\
Also würde ich mal annehmen, dass es (nach Anpassung an deine konkreten Geräte) mit einem einfachen publish an deinem MQTT-IO (TYPE=MQTT) gehen sollte:
set <mqtt-io> publish shellies/<shelly-name>/command update_fw
genau so wie du es vorschlägst habe ich es auch versucht, auch schon vorher, nur leider sehe ich keine neuen Daten in den readings
an announce message on shellies/announce. The message is json-formatted and contains a list of attributes: id, mac, ip, new_fw is true when an update is available, fw_ver contains the current firmware version.
availability message on shellies/<shellymodel>-<deviceid>/online with payload true
complete current state. This is device specific and is described in detail for each device below.
mit dieser Beschreibung komme ich nicht klar.
hier ist ein list meines devices
Internals:
FUUID 5c42eaa9-f33f-fbda-ad2e-c820baf92017625f
IODev myBroker
NAME shelly_Keller
NR 574
STATE off
TYPE MQTT_DEVICE
OLDREADINGS:
READINGS:
2019-06-06 17:16:01 Energie 5856
2019-06-06 17:16:00 Licht off
2019-06-06 17:16:01 Power 0.00
2019-06-06 17:13:11 state publish
2019-06-06 17:16:01 transmission-state incoming publish received
helper:
message_ids:
publishSets:
:
topic shellies/shellyswitch-32BCCD/relay/0/command
values:
on
off
sets:
off
on
subscribe:
shellies/shellyswitch-32BCCD/relay/energy
shellies/shellyswitch-32BCCD/relay/0
shellies/shellyswitch-32BCCD/relay/power
shellies/shellyswitch-32BCCD/announce
subscribeExpr:
^shellies\/shellyswitch-32BCCD\/relay\/energy$
^shellies\/shellyswitch-32BCCD\/relay\/0$
^shellies\/shellyswitch-32BCCD\/relay\/power$
^shellies\/shellyswitch-32BCCD\/announce$
subscribeQos:
shellies/shellyswitch-32BCCD/announce 0
shellies/shellyswitch-32BCCD/relay/0 0
shellies/shellyswitch-32BCCD/relay/energy 0
shellies/shellyswitch-32BCCD/relay/power 0
subscribeReadings:
shellies/shellyswitch-32BCCD/announce:
cmd
name announce
shellies/shellyswitch-32BCCD/relay/0:
cmd
name Licht
shellies/shellyswitch-32BCCD/relay/energy:
cmd
name Energie
shellies/shellyswitch-32BCCD/relay/power:
cmd
name Power
Attributes:
IODev myBroker
devStateIcon on:rc_GREEN:off off:rc_RED:on
group Licht
publishSet on off shellies/shellyswitch-32BCCD/relay/0/command
room 0.1.Keller,9.9.System->Licht,Homekit,MQTT
stateFormat {ReadingsVal("shelly_Keller","Licht",'')}
subscribeReading_Energie shellies/shellyswitch-32BCCD/relay/energy
subscribeReading_Licht shellies/shellyswitch-32BCCD/relay/0
subscribeReading_Power shellies/shellyswitch-32BCCD/relay/power
webCmd on:off
Hmm, nach der Beschreibung kommt auch nur was an
shellies/announce
Dafür gibt es aber keine subscription (der Topic-Pfad ist auch irgendwie seltsam), sondern du hast das nur mit dem devicespezifischen Element zwischendurch (was sinnvoll wäre).
Vielleicht wäre es zielführend, wenn du am Web-IF des Teils schaust, ob der Befehl denn angenommen wurde? (also welche fw jetzt werkelt...)
Genau das ist es, es passiert nirgends was.
Ich habe jetzt mit MQTT.fx sämtliche readings und auch einen scan gemacht, keine Veränderungen.
Gleichzeitig hab ich dem Hersteller des shellies geschrieben, mal schauen was der für Antwort liefert, werde diese dann hier posten.
Danke auf jedenfall!
Leider kamen vom Hersteller nur die gleichen Inputs wie schon bekannt, also nichts neues.
Hi,
falls noch jemand an dem Thema hängt - die Shellies haben wohl eine Art Sammelkanal.
Ich habe mal mit MQTT.fx ein
Publish auf shellies/command mit dem Inhalt announce gemacht.
Danach habe ich von allen Shellies die hier gerade laufen eine Antwort unter shellies/announce bekommen.
Wohl gemerkt alle shellies senden ein shells/announce nur der Inhalt der Nachricht ist jeweils anders - zB.:
{"id":"shellyswitch25-xxxxxx","mac":"84F3EBxxxxxx","ip":"10.0.0.232","new_fw":false, "fw_ver":"20190822-102551/v1.5.3@1c2d4dd5"}
Jetzt leibt nur, ob man das irgendwie als ein Gerät in FHEM dargestellt bekommt.
Also z.b. ein Gerät das in den Readings immer alle Infos der einzelnen Shellies listet - habe nur keine Idee wie man das in FHEM bauen könnte...
Die Befehle Announce, Update und Update_FW wäre ja noch einfach...
Ich habe gerade MQTT2_DEVICE erweitert, so dass ClientId fuer readingsList als $CID zur Verfuegung steht.
Damit erzeugt:define announceDev MQTT2_DEVICE
attr announceDev readingList shellies/announce:.* { json2nameValue($EVENT, $CID."_") }
ausmosquitto_pub -i testme2 -t shellies/announce -m '{"id":"shellyswitch25-xxxxxx","mac":"84F3EBxxxxxx","ip":"10.0.0.232","new_fw":false, "fw_ver":"20190822-102551/v1.5.3@1c2d4dd5"}'
die folgenden Readings: 2019-10-06 22:17:43 testme2_fw_ver 20190822-102551/v1.5.3@1c2d4dd5
2019-10-06 22:17:43 testme2_id shellyswitch25-xxxxxx
2019-10-06 22:17:43 testme2_ip 10.0.0.232
2019-10-06 22:17:43 testme2_mac 84F3EBxxxxxx
2019-10-06 22:17:43 testme2_new_fw false
ClientId gibts leider nur in Verbindung mit MQTT2_SERVER.
@Rudi: Danke erst mal.
@all: die shelly-attrTemplates (für MQTT2_DEVICE) haben (seit dem letzten update) in der Regel ein Ampelsystem, das offene updates als "gelben Punkt" anzeigt; durch "Klicken" darauf wird direkt das update angestoßen.
Frage mich grade, ob es Sinn macht, da (auch) sowas wie ein zentrales Updatedevice anzubieten.
Für MQTT_DEVICE ist es etwas komplizierter, da kann man aber auch Perl verwenden, müßte dann aber erst das Device ("id") via Regex extrahieren und an json2nameValue() übergeben...
Zitat
- attr <name> subscribeReading_<reading> [{Perl-expression}] [qos:?] [retain:?] <topic>
mapps a reading to a specific topic. The reading is updated whenever a message to the configured topic arrives.
QOS and ratain can be optionally defined for this topic.
Furthermore, a Perl statement can be provided which is executed when the message is received. The following variables are available for the expression: $hash, $name, $topic, $message. Return value decides whether reading is set (true (e.g., 1) or undef) or discarded (false (e.g., 0)).
Example:
attr mqttest subscribeReading_cmd {fhem("set something off")} /topic/cmd
Hi,
Wollte das mal testen, aber bekomme leider folgende Meldung, wenn ich ein:
attr announceDev readingList shellies/announce:.* { json2nameValue($EVENT, $CID."_") }
Global symbol "$CID" requires explicit package name (did you forget to declare "my $CID"?) at (eval 901297) line 1.
Gruß
Carlos
Hast du version 20324 von MQTT2_DEVICE (und bezieht sich das readingList-Attribut auf ein solches)?
Ja, so wie das define oben.
10_MQTT2_DEVICE.pm 20324 2019-10-06 20:14:49Z rudolfkoenig
OK, geht auch bei meiner Trockenübung auf einem Strawberry-Perl nicht....
Habt ihr evtl. nach dem update FHEM nicht neu gestartet?
Habe nochmal mit folgendem fhem.cfgattr 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.
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
Ebenso bei mir, update fhem restart.
Perl auch bei mir 5.28.1
Nach einem
define announceDev MQTT2_DEVICE
und
attr announceDev readingList shellies/announce:.* { json2nameValue($EVENT, $CID."_") }
kommt diesen Fehler.
Gibt es in eurem 10_MQTT2_DEVICE.pm folgende Zeile?
"%CID"=>$cid, "%JSONMAP","\$defs{$dev}{JSONMAP}"));
Habs auch mit 5.28.1 jetzt nachgetestet, kein Unterschied. Ratlos.
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?
Peinlich :)
Habe eine neue Version eingecheckt.
:)
Ein allg. update-Device könnte dann so aussehen:
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.
Top, funktioniert:
In der api docu steht folgendes:
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
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"}
...das ergäbe dann folgendes template:
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... ;D .
Hallo,
Ist das schon eingecheckt? Ich kriege folgendes (raw def):
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
Zitat von: tomleitner am 26 November 2019, 19:27:07
Hallo,
Ist das schon eingecheckt?
Ggf. update und danach mal
set ShellyDevList attrTemplate ?ausführen sollte die Frage auf einfache Weise beantworten....
Zitat von: Beta-User am 27 November 2019, 08:01:35
Ggf. update und danach mal
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:
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
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".)
Zitat von: Beta-User am 27 November 2019, 10:45:13
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:
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
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:
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?
Danke Dir ... ja das reicht als Anregung ... werde das mit der erweiterten readingList probieren ....
Ich bin nun nicht der große Perl Guru wie man aus meinem Codeschnipsel sehen kann, aber meine Lösung war nun folgende readingList:
shellies/announce:.* { my $id=$EVENT; $id=~s/.*id":"//; $id=~s/".*//; json2nameValue($EVENT, $id . "_" ) }
hier wird über regexp die ID aus dem JSON string gekitzelt. Eleganter wäre es gewesen json2nameValue zweimal aufzurufen, einmal um die 'id' zu bekommen und das zweite Mal um diese 'id' als prefix zu benutzen. Mangels tieferer Kenntnisse konnte ich das aber nicht umsetzen.
So funktionierts aber auch ...
Ausgehend von dem (https://forum.fhem.de/index.php/topic,101216.msg981339.html#msg981339) hier müßte eigentlich auch das hier passen (das Umpacken gefällt mir nicht so recht):
shellies/announce:.* { $EVENT =~ m,id...([^"]+), ? json2nameValue($EVENT,$1."_") : json2nameValue($EVENT) }
Ja, schaut auch gut aus ... Danke.
Hallo,
um die FW aller meiner installierten Shellys automatisch und "gleichzeitig" upzudaten habe ich bisher die Shelly Home APP von Dirk Gausmann verwendet. Nachdem diese bei mir aus unerfindlichen Gründen nicht mehr funktioniert und auch die neue Windows-Version davon ebensowenig funktioniert muß ich bei jedem Shelly die FW wieder einzeln updaten. Das ist ein riesen Aufwand.
Deshalb würde ich gerne die FW meiner (per MQTT2 angebundenen) Shellys über FHEM aktuallisieren. In diesem Zusammenhang bin ich auf diesen Thread gestoßen. Ich habe mir alle Beiträge hier durchgelesen, aber irgendwie verstehe ich die Zusammenhänge nicht.
Meine Annahmen/Fragen:
- Um zu erkennen ob es für einen Shelly ein neues Update gibt wird hier ja das "new_fw"-Attribut ausgewertet, soweit klar, aber
- wie soll dieses Attribut gefüllt werden wenn der Shelly keine Internetverbindung zum Shelly Cloud-Server hat?
- Wie wird die aktuelle FW durch FHEM vom Shelly-Server geholt?
- Erst wenn man die aktuelle FW vom Shelly Cloud-Server geholt hat, bzw. (falls es so etwas gibt) aus einer Liste die Nr. der neuesten Version heruntergeladen hat kann doch FHEM diese mit der aktuell installierten Version auf dem Shelly vergleichen, das "new_fw"-Attribut setzen und dann automatisch oder manuell diese auf den Shelly laden, oder?
Kann mir das Ganze vielleicht Jemand erklären. Ich stehe absolut auf dem Schlauch.