ShellyPro1PM und MQTT

Begonnen von VolkerGBenner, 14 März 2023, 14:00:48

Vorheriges Thema - Nächstes Thema

VolkerGBenner

Hallo an alle Wissenden.

Ich habe jetzt ein ShellyPro1PM und nutze es über mqtt2_server. Das Gerät haut im Sekundentakt seine Nachrichten raus. Kann man das irgendwie reduzieren? Ich finde auf der Weboberfläche des Shellys nichts.

Ist das attrTemplate des Shelly1PM brauchbar für das Pro1PM? Wenn ich es als Shelly-Gerät anlege, bekomme ich quasi keine nutzbaren Informationen angezeigt.
defmod PV_Einspeisung Shelly 192.168.2.99
attr PV_Einspeisung model shelly1pm
attr PV_Einspeisung room Energie
attr PV_Einspeisung shellyuser brockenberg
#   DEF        192.168.2.99
#   FUUID      63fc8f16-f33f-1c7b-be07-775dffd6202b9c1b
#   INTERVAL   60
#   NAME       PV_Einspeisung
#   NR         126
#   STATE      Error
#   TCPIP      192.168.2.99
#   TYPE       Shelly
#   eventCount 4
#   READINGS:
#     2023-03-14 13:17:00   network         <html>connected to <a href="http://192.168.2.99">192.168.2.99</a></html>
#     2023-03-14 13:18:00   state           Error
#
setstate PV_Einspeisung Error
setstate PV_Einspeisung 2023-03-14 13:17:00 network <html>connected to <a href="http://192.168.2.99">192.168.2.99</a></html>
setstate PV_Einspeisung 2023-03-14 13:18:00 state Error



Gruß
Volker
1x  RasPiB3+  mit RPI-RF-MOD und piccu3
1x HM-TC-IT-WM-W-EU, 1x HM-CC-RT-DN, 1xHM-SEC-SCo,
HM-LC-Sw4-DR, HM-WDS30-OT2-SM, HM-Dis-WM55, 7x HmIP-eTRV-B,

Beta-User

a) ein Shelly-TYPE-listing bringt für MQTT relativ wenig. In jedem Fall dürfte "model shelly1pm" nicht passen, denn

b) die "plus"- und "pro"-Geräte verwenden die "Gen 2 Device API". Die ist anders, also würde der Versuch auch nichts bringen, das MQTT2-attrTemplate für den shelly1pm darauf anzuwenden.

c) Es gab/gibt bereits ein paar abgebrochene Threads zu dieser Type, ohne dass mir im Moment klar ist, ob das jetzt irgendwie funktioniert oder nicht, und was ggf. das Problem ist. Es wäre vermutlich besser gewesen, wenn du dich mit der Frage da rangehangen hättest.

d) Was man für den MQTT-Bereich braucht, ist angepinnt.

e) Wenn es viele Aktualisierungen gibt, kann das auch daran liegen, dass sich Werte schnell ändern, v.a. bei PV-Anlagen soll das schon mal vorkommen... Vielleicht (!) kann man eine Hysterese setzen, siehe https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/Voltmeter/#configuration. Ist aber ein Schuss ins Blaue, weil (d))...

Ach so: für ein eher "spammiges Verhalten" via MQTT waren die Shelly-Geräte schon immer "berühmt"...
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

sash.sc

Benutze event-on-change oder Event-min-intervall als Attribut.

Gruß Sascha
Raspi 4B+ Bullseye ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; Grafana mit Influxdb