Shelly‘s über mqtt update

Begonnen von australien, 06 Juni 2019, 15:38:01

Vorheriges Thema - Nächstes Thema

australien

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
raspberry pi3
signalduino, Shelly1, Shelly2, Sonos, Unifi
Amazon Fire Tablet 7 | Noname Android Tablet 10"

Beta-User

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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

australien

@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.
raspberry pi3
signalduino, Shelly1, Shelly2, Sonos, Unifi
Amazon Fire Tablet 7 | Noname Android Tablet 10"

Beta-User

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
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

australien

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

raspberry pi3
signalduino, Shelly1, Shelly2, Sonos, Unifi
Amazon Fire Tablet 7 | Noname Android Tablet 10"

Beta-User

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...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

australien

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!
raspberry pi3
signalduino, Shelly1, Shelly2, Sonos, Unifi
Amazon Fire Tablet 7 | Noname Android Tablet 10"

australien

Leider kamen vom Hersteller nur die gleichen Inputs wie schon bekannt, also nichts neues.
raspberry pi3
signalduino, Shelly1, Shelly2, Sonos, Unifi
Amazon Fire Tablet 7 | Noname Android Tablet 10"

Magic01

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...

rudolfkoenig

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.

Beta-User

@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
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

carlos

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
FHEM svn auf Intel NUC mit proxmox,1 UDOO, 3 Raspberry Pi, signalduino, nanoCUL, div. Homematic Komponenten, toom Baumarkt Funksteckdosen, einige sonoffs, hue, shelly

Beta-User

Hast du version 20324 von MQTT2_DEVICE (und bezieht sich das readingList-Attribut auf ein solches)?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

carlos

Ja, so wie das define oben.
10_MQTT2_DEVICE.pm 20324 2019-10-06 20:14:49Z rudolfkoenig
FHEM svn auf Intel NUC mit proxmox,1 UDOO, 3 Raspberry Pi, signalduino, nanoCUL, div. Homematic Komponenten, toom Baumarkt Funksteckdosen, einige sonoffs, hue, shelly

Beta-User

OK, geht auch bei meiner Trockenübung auf einem Strawberry-Perl  nicht....
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files