Shelly pro 3EM im WIKI

[63chris]

es haben schon mehrere user im Forum bzgl. der Einbindung gefragt, die ja anders als beim alten 3EM ist.
Gerade Neueinsteiger suche da nach Hilfe

Evtl. kann man ja diesen als zusätzl. Beispiel mit ins WIKI aufnehmen?
Kenne mich selber nicht mit Github pull requests aus, hatte das alles schon hier mal zusammengefaßt
https://homematic-forum.de/forum/viewtopic.php?f=85&t=69535&p=785621&hilit=3em#p785621

[mdzio]

Danke. Ich werde das bei Gelegenheit ins Wiki einpflegen.

[martinrieder]

Danke für den Hinweis zum Forum. Ich habe meinen Pro 3EM etwas anders als in der Beschreibung über das Gerät HM-ES-PMSw1-Pl (Schaltaktor mit Leistungsmessung) konfiguriert. Mangels Anleitung hatte ich das selbst augetüftelt... Ich verwende aber kein TEMPLATE mit parseJSON (vgl. #70), sondern einfach nur Textmuster mit AFTER:

Topic lautet hierfür: shellypro3em-[Seriennummer]/status/em:0

Es funktioniert soweit auch ganz gut, allerdings habe ich neuerdings ein Balkonkraftwerk und stehe nun vor dem Problem, dass keine negativen Werte für Leistung und Strom ankommen. Bevor ich jetzt aber ein neues Issue aufmache, möchte ich erst mal nach Details zur verwendeten Funktion parseJSON fragen. Ich möchte nämlich gerne verstehen, ob es sich hierbei um einen Bug oder einfach nur um eine Fehlkonfiguration meinerseits handelt.

PS: mit "keine negativen Werte" meine ich, dass nur das Vorzeichen verschluckt wird. Es kommen also schon Daten an, allerdings mit positivem Betrag.

Neue Erkenntnis: Der Shelly liefert als Strom immer nur positive Werte, aber die Leistung kommt mit Vorzeichen daher. Als ich den durchgestrichenen Text oben geschrieben habe, schien leider keine Sonne mehr, um das zu bemerken.

Für {{(parseJSON .).a_act_power}} und {{(parseJSON .).a_current}} erhalte ich folgende Meldung im Debug-Log:

2024-08-07 15:18:43	WARNING	virt-dev	Extraction of value for analog receiver JACK000002:1.CURRENT failed: Template returned invalid number literal: 0.547
2024-08-07 15:18:43	DEBUG	virt-dev	Message for JACK000002:1.CURRENT received: shellypro3em-1234567890/status/em:0, {"id":0,"a_current":0.547,"a_voltage":232.7,"a_act_power":-120.2,"a_aprt_power":127.3,"a_pf":0.95,"a_freq":50.0,"b_current":…
2024-08-07 15:18:43	WARNING	virt-dev	Extraction of value for analog receiver JACK000002:1.POWER failed: Template returned invalid number literal: -120.2
2024-08-07 15:18:43	DEBUG	virt-dev	Message for JACK000002:1.POWER received: shellypro3em-1234567890/status/em:0, {"id":0,"a_current":0.547,"a_voltage":232.7,"a_act_power":-120.2,"a_aprt_power":127.3,"a_pf":0.95,"a_freq":50.0,"b_current":0.…
2024-08-07 15:18:43	DEBUG	itf-l-client	Calling method event(CCU-Jack, JACK000002:2, CURRENT, 0.027) on 127.0.0.1:2098

Ich stelle für mich nun wieder auf die einfache Methode um, weil parseJSON zusammen mit HM-ES-PMSw1-Pl nicht funktioniert. Ich würde mir aber noch eine nähere Beschreibung der Funktion wünschen. Eventuell gibt es hier ja einen Bug, den es näher zu beleuchten gilt.

[mdzio]

Ich habe es gerade mit folgenden Einstellungen getestet, wie in Deinem Beitrag angegeben:

Mit der Payload {"id":0,"a_current":0.547,"a_voltage":232.7,"a_act_power":-120.2,"a_aprt_power":127.3,"a_pf":0.95,"a_freq":50.0} wird wie erwartet der Analogeingang gesetzt:

Es ist merkwürdig, dass es bei Dir nicht funktioniert.

[martinrieder]

Okay, danke. Ich bin gerne bereit, da nochmal etwas tiefer zu bohren. Der offensichtliche Unterschied ist natürlich, dass ich hier keinen Analogeingang verwende. Wie das mit dem Fehler zusammenhängen könnte, verstehe ich nicht.

Ich habe aber mal im Code wegen o.g. Fehlermeldung gesucht und bin hier fündig geworden:
https://github.com/mdzio/ccu-jack/blob/master/virtdev/mqtt.go#L266-L269

        fval, err := strconv.ParseFloat(sb.String(), 64)
        if err != nil {
                return 0.0, fmt.Errorf("Template returned invalid number literal: %s", sb.String())
        }

Der Text ist also etwas irreführend, denn es wird nicht der Rückgabewert von ParseFloat angezeigt, sondern der zu verarbeitende String. Dass dieser zum Payload passt und auch das Vorzeichen korrekt ist, sind schon mal gute Nachrichten. Wie könnte man hier noch weiter debuggen?

PS: Da wir uns nun fernab des ursprünglichen Themas bewegen, sollte ich wohl besser ein separates Issue anlegen. Wichtig wäre mir nur, dass die mit #70 eingeführte Funktion im Wiki etwas näher beschrieben wird. Die Syntax ist schließlich nicht selbsterklärend. Mit der oben beschriebenen Lösung per Textmuster ist es dagegen deutlich einfacher und funktioniert zumindest bei mir problemlos.

[mdzio]

Mir ist noch eine weitere Fehlerursache eingefallen und habe sie soeben getestet: Fall sich vor den {{ oder nach den }} im PATTERN noch Leerzeichen befinden, dann schlägt ParseFloat leider ebenfalls fehl. Bitte mal prüfen.

[martinrieder]

Okay, das kann ich bestätigen: am Leerzeichen hat es wohl gelegen. Dann funktioniert beides unabhängig vom gewählten Gerät.

Selbiges gilt übrigens auch beim Textmuster, aber hier ist es offensichtlich, dass im Payload kein Leerzeichen nach dem Doppelpunkt steht.

Ich werde dann ein Issue erstellen, um ParseFloat etwas robuster zu machen. In der oben kopierten Meldung aus dem Debug Log ist das Leerzeichen auch zu finden. Man muss dafür aber schon genau hinschauen.

[martinrieder]

Fürs Wiki noch zwei Screenshots, versehen mit dem Hinweis, dass beim Gerätetyp HM-ES-PMSw1-Pl (Schaltaktor mit Leistungsmessung) automatisch für jeden Energiezähler-Kanal ein systeminternes Skript angelegt wird, um den Zählerstand zu sichern. Es ist wohl Geschmackssache, ob man die Funktionen haben möchte oder lieber einfach nur einen Analogwertgeber ohne zusätzliche Intelligenz...

Wenn ich mal dazu komme, das zusätzliche Relais noch in Betrieb zu nehmen, dann poste ich ein Update zum Kanal Nr. 4 für den Schalter.

Das Issue zu den oben genannten Themen habe ich erstellt:

• Verbesserung der Behandlung von Leerzeichen mit MQTT #185

PS: Einen kleinen Schönheitsfehler gibt es noch bei der Einheit des Stroms. Dieser wird beim gewählten Gerät in mA angegeben, aber per MQTT in A geliefert. Das müsste eigentlich noch mit dem Faktor 1000 multipliziert werden.

[mdzio]

Danke für die Wiki-Ergänzungen.

PS: Einen kleinen Schönheitsfehler gibt es noch bei der Einheit des Stroms. Dieser wird beim gewählten Gerät in mA angegeben, aber per MQTT in A geliefert. Das müsste eigentlich noch mit dem Faktor 1000 multipliziert werden.

Das ist mit der Templatefunktion mul möglich: Beispiel: {{ mul (parseJSON .).ENERGY.Total 1000 }}

[martinrieder]

PS: Einen kleinen Schönheitsfehler gibt es noch bei der Einheit des Stroms. Dieser wird beim gewählten Gerät in mA angegeben, aber per MQTT in A geliefert. Das müsste eigentlich noch mit dem Faktor 1000 multipliziert werden.

Das ist mit der Templatefunktion mul möglich: Beispiel: {{ mul (parseJSON .).ENERGY.Total 1000 }}

Das funktioniert super. Danke!

Zu den MQTT-Einstellungen zusammen mit dem o.g. Schaltaktor ist mir noch eine erwähnenswerte Sache aufgefallen, die auch unbedingt ins Wiki sollte:

• Der Wert für ENERGY_CONTER läuft unter Topic
  shellypro3em-[Seriennummer]/status/emdata:0
• Alle anderen Datenpunkte mit Momentanwerten sind im Topic
  shellypro3em-[Seriennummer]/status/em:0

Der Unterschied zwischen emdata und em mag nicht jedem direkt ins Auge springen. Ich hatte einen zweiten Shelly angelegt und mir ist das beim Copy&Paste auch nicht gleich aufgefallen. Erschwert wird die Situation dadurch, dass die Textfelder zu kurz sind, um das Topic komplett anzuzeigen.