Modul 36_ShellyMonitor

Begonnen von gvzdus, 16 Januar 2021, 14:18:47

Vorheriges Thema - Nächstes Thema

gvzdus

Grundsätzlich ja, wobei bei Paketverlusten im lokalen Netz auch mal ein Paket unter den Tisch fallen kann. Ich würde einfach mal schätzen: Mit COAP sollte es in 99,9% der Fälle funktionieren, gefühlt immer.

gvzdus

Ich habe heute den ShellyMotion erhalten. Funktioniert, UI nett gemacht.

Bei ShellyMonitor war ein Anpassung erforderlich, weil beim ShellyMotion die CoIoT-Nachricht ein Token enthält - hatte ich bisher nicht berücksichtigt. Die Änderung ist eingecheckt und morgen im regulären Update verfügbar.

Nicht ganz überraschend heißen die beiden Readings "motion" und "vibration" mit 0 und 1. Daneben kommt noch die "luminosity" sowie 2 Werte, die Shelly nicht dokumentiert hat - ich habe nachgefragt, aber noch keine Antwort.

gvzdus

Bad news
Allterco wird das Multicast in künftigen Versionen erst optional machen, und dann aufgeben, wie Dimitar auf Facebook angekündigt hat. Die aktuelle 1.10-FW des Shelly-Motion kann nur noch Unicast, also "Server:IP".

Was bedeutet das?

  • Ohne die Multicast-Messages läuft die Auto-Erkennung der Shellys im Netz nicht. "Ich" könnte auf mDNS wechseln, ist so aber noch nicht implementiert
  • Das schöne "einfach Devicenamen eingeben und klicken" - Gerät ist da, klappt auch so wie jetzt dann nicht mehr, denn der Server muss im Frontend aktiv konfiguriert werden
  • Einer der Vorteile ggü. MQTT ist weg: Die Möglichkeit, redundant auf mehreren FHEM-Instanzen Nachrichten zu empfangen. Allerdings erlaubt die FW des Shelly-Motion, eine Broadcast-Adresse einzugeben (192.168.0.255 z.B.), und dann klappt es wieder mit mehreren Instanzen

Warum?
Um es im Stoiber-Deutsch zu stammeln: Ein gewisser Professor aus Karlsruhe wird breit grinsen: Man hat gemerkt, dass die ganzen Pakete im Netz jetzt mit den batteriegetriebenen Always-On-Wifi-Geräten auf die Akkukapazität gehen.

Was kann man / ich tun?

  • mDNS implementieren und darüber Shellys listen
  • mindestens eine neue Version herausbringen, die entweder auf Unicast oder Multicast lauscht. Dann wird man vorübergehend zwei Shelly-Monitor-Instanzen brauchen: Eine für Unicast und eine für Multicast
  • Bisher wollte ich nicht invasiv sein, also Shellys "konfigurieren". Wenn es so einfach wie jetzt bleiben soll, dann müsste ich aber mindestens wohl den CoIoT-Server oder Broadcast aktiv am Shelly konfigurieren. Dann könnte man auch gleich darüber nachdenken, alternativ anzubieten: Was möchtest Du? MQTT oder CoIot mit ModShelly?

Alles erst mal meine ersten Gedanken... Unten den Screenshots der Settings von FW 1.10beta5 (für diverse Shellys) und FW 1.10 (für ShellyMotion)

Prof. Dr. Peter Henning

Ach, der gewisse Professor aus Karlsruhe ist bei Forschungsanträgen gewohnt, dass wochenlange harte Arbeit für die Katz war.

Willkommen im Club.

LG

pah

bombardi

Seit dem Update auf 1.10 wird die Firmwareversion nicht mehr korrekt ausgelesen, kann das evtl. am Shellymonitor liegen ?
pah habe ich schon im https://forum.fhem.de/index.php/topic,118446.msg1141122.html#msg1141122 mit weiteren Informationen gefragt.

gvzdus

Ja, ich werde mich heute ransetzen, es wieder zum Laufen zu bringen. Update ist morgen da, ich hänge es auch hier in den Thread.

gvzdus

Habe geguckt. Nein, "ShellyMonitor" ist unschuldig. Man muss mit 1.10 nur beachten, dass CoIoT eingeschaltet ist und auf "mcast" steht - siehe auch mein Screenshot weiter oben vom Release-Candidate. Aber Multicast ist abgekündigt und daher muss ich da ran, allerdings nicht ultimativ heute.

bombardi

Meine stehen alle auf mcast und sind enabled

münster

Hallo in die Runde.

Wenn ich das hier vorgestellte Tool und die vorherigen Seiten zu diesem Topic richtig verstehe, liefert es bei meinem Shelly1 + Temp Addon die entsprechenden Readings extTemp_0 und extTemp_0f quasi in Echtzeit.
Hab das Tool jetzt auch drei Tage laufen lassen und nun lässige 10.000 Events gehabt. Sind mir ein wenig viele gewesen. Ohne Tool hatte ich die Shellys auf einen Intervall von 60 Sek eingestellt, was aber, auch gemäß Zweck des Tools, ignoriert wird und permanent Daten liefert.

Ohne Tool schickt Shelly mir diese Daten aber eben garnicht. Alternative wäre, wenn ich´s richtig verstehe, wohl den Shelly über MQTT einzubinden.

Gibt es einen Tipp wie ich an die o.g. Readings in größeren Abständen komme? Beispielsweise nur alle 5 Minuten? Denn so schnell ändert sich die Temperatur in meiner Garage eher nicht.

Würde mich freuen wenn sich Jemand kurz äußern würde. Ich bin leider nicht der große Programmierer, sondern eher der Probierer. Mein SmartHome ansich hab ich, auch dank der vielen Beiträge hier im Forum, bisher ganz gut hinbekommen. Aber hier steh ich etwas auf dem Schlauch. Also bitte um Nachsicht.

Im Voraus vielen Dank.

gvzdus

Erst einmal: Ich werde ShellyMonitor absehbar umbauen müssen, da Allterco den CoIoT-Multicast abgekündigt hat. Aber noch betrifft Dich das nicht.

Zur Frage: Wenn es Dir zu viele Events sind, guck' Dir mal in der FHEM-Doku "event-aggregator" an. Damit legst Du fest, wie die Messwerte gemittelt werden und in welcher Frequenz Du ein Event haben willst. Funktioniert prima, und ist genauer als z.B. nur alle 10 Minuten einen Messwert zu ziehen.

münster

Super danke für die schnelle Rückinfo. Werd mir "event-aggregator" anschauen.

Ja, hab ich schon gelesen, dass perspektivisch das Thema CoIoT ansteht. Hoffe du bekommst das hin und stellst es dann auch weiterhin zur Verfügung! Also noch gehts ja auch! Dafür schonmal ein großes Danke!  ;)

Bin ja auch froh das es mit deinem Tool funktioniert. Hätte ja garnicht gedacht, dass sonst die Readings garnicht kommen.

Bis dahin weiterhin maximale Erfolge und Elan!

Prof. Dr. Peter Henning

ZitatHätte ja garnicht gedacht, dass sonst die Readings garnicht kommen.

Wieso? 36_Shelly.pm liest sie doch aus.

Allerdings unter anderem Namen.

LG

pah


RalfRog

Hallo Münster

Evtl könnte für CoIoT die "coiot_update_period" zur Paket-Reduzierung von 15 Sekunden auf höhere Werte geändert werden.

<Shelly-IP>/settings?coiot_update_period=60 oder 300 (Sekunden)

Gruß
FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

münster

Zitat von: Prof. Dr. Peter Henning am 01 April 2021, 06:13:00
Wieso? 36_Shelly.pm liest sie doch aus.

Allerdings unter anderem Namen.

LG

pah

Hab´s nochmal versucht nachzustellen. Scheinbar wurde erst ein Neustart von FHEM erforderlich, dass er die Readings temperature_0 und humidity_0 gemeldet wurden.
Davor wurde garnichts gemeldet. Mit dem ShellyMonitor kamen dann extTemp_0 und extTemp_0f. Aber eben mit für mich zu geringen Intervallen.

Jetzt nach Neustart erkennt er temperature_0 und humidity_0 und meldet diese eben auch im vorgegebenen Intervall.
Also danke für den Anstoss in dieser Richtung.

@RalfRog
Damit brauch ich den Vorschlag von dir nicht mehr anfassen. Aber trotzdem Danke, dass du noch eine Idee bringen konntest. Wäre ich von mir aus, nicht drauf gekommen.

gvzdus

Wo hier Leute mit Temp-Sensor mitlesen: Ich hatte übrigens bisher 2-mal das Problem, dass mein Shelly 1PM "vergaß", dass er externe Sensoren hat. Sie wurden einfach nicht mehr angezeigt: Nicht in der Web-GUI, nicht per CoIoT. Nach einem Reboot waren sie wieder da. Der Fehler ist aber zuletzt vor einem Monat aufgetreten - vielleicht ein Softwarefix? Aber meldet es doch, wenn's bei Euch auch auftritt.

Zum Fortschritt bei Mod_ShellyMonitor:
Gestern habe ich den Feiertag genutzt, um erst mal die Grundstruktur eines mDNS-Sniffers zu schreiben (der Vorläufer von ShellyMonitor war ja auch der "shellysniffer"). Nervig: Wie auch bei CoIoT *scheint* es so zu sein, dass Allterco auch hier nicht sauber für die Batteriegeräte wie den ShellyMotion im mDNS eine TTL setzt, und sich vor Ablauf wieder meldet. Aber immerhin bietet mDNS ggü. CoIoT halt das "AutoDiscovery"-Feature.

Nun denke ich über die Transition nach. Im Standardmodell kann ein Shelly-Modul nur einen Socket lesen. Ich brauche aber:

  • den "alten" CoIoT-MCast-Listener
  • den "neuen" CoIoT-UniCast-Listener
  • einen neuen mDNS-MCast-Listener

Ein mDNS-MCast-Modul ergibt natürlich auch unabhängig von ShellyMonitor Sinn. Aber 3 Module? Naja, ich grübele halt noch.