Modul 36_ShellyMonitor

Wetterhexe · 18 Januar 2021, 13:12:11

Zitat von: gvzdus am 18 Januar 2021, 09:38:55Wenn Du die angehängte Version vorab testen kannst, wäre es gut - sonst ist sie morgen per Update verfügbar.

hab sie gerade eingespielt ... läuft perfekt! Vielen Dank für den schnellen fix!

betateilchen · 18 Januar 2021, 15:46:28

Wenn man ein solches Modul baut und eincheckt, das zusätzliche, vom FHEM Standard abweichende perl Pakete (Multicast) voraussetzt, sollte man diese Abhängigkeiten auch in der commandref beschreiben!

gvzdus · 18 Januar 2021, 16:12:39

Ist erledigt und in der Version morgen drin.

MadMax-FHEM · 18 Januar 2021, 22:46:00

Zitat von: MadMax-FHEM am 18 Januar 2021, 10:34:05
Ich werde das heute Abend (wenn tatsächlich Zeit ist/bleibt) mal testen...
...und außerdem: hänge ich jetzt hier auch "dran"

Gruß, Joachim

So: "gesagt getan"

Also IP-Adresse ändern geht

(sofern die Shelly dann auch irgendwann mal mit der neuen IP Messages verschicken, da ist wohl bei "denen" noch was "verquer")

Allerdings stimmt die Anzahl an "Devices" nicht mehr.

Also: alte IP -> 1 Device / IP ändern -> 2 Devices usw.

Nicht schlimm aber etwas "verwirrend"...

Und: wie kann ich Devices aus der Tabelle löschen?

Mal angenommen (was ich ja zum Testen, okok

öfter vorkommt) ich habe mal einen Shelly in Betrieb genommen und dann beschlossen, dass ich ihn doch nicht brauche oder er defekt ist (hatte ich bei einem der Shelly 1L / gekauft, angeschlossen und gemerkt, dass "Schalter-Eingang-1" einen Defekt hat: ging nicht)...

Wie werde ich den jemals wieder los?

Aktuelle "Lösung": delete ShellyMonitor / define ShellyMonitor... (unschön)

Gruß, Joachim

gvzdus · 18 Januar 2021, 22:51:54

Hi Joachim,
Geräte, die nicht mehr da sind, sollten nach etwa 65 Minuten verschwinden. Die Multicast-Pakete enthalten eine TTL, im verbose 5-Log als "validity" aufgeführt werden. Die werte ich aus, und nach Ablauf sollte das Gerät in der Tabelle verschwinden:

Code Auswählen

URI: /cit/s, global_devid = SHPLG-S#B86612#2, validity=3840, serial=57406

MadMax-FHEM · 18 Januar 2021, 22:54:32

Ah, ok, zu ungeduldig

Andere Alternative: Device anlegen und dann löschen... Damit ist es aus der Liste raus und kommt/käme erst wieder, wenn es neu sendet.

Also passt...

Gruß, Joachim

Paul · 18 Januar 2021, 23:35:40

Hallo, habe ich es richtig verstanden, dass das Modul nur Readings und das Shelly Modul schreibt, die dort auch aufgeführt sind?

Konkret: ich habe einen Shelly1 mit AddOn Temperatur und Feuchte und bei anderen Modulen auch on/off werden vom Shelly übertragen aber nicht im Shelly Modul übernommen?

gvzdus · 18 Januar 2021, 23:38:08

Probier's aus. Wenn die Werte nicht ankommen, leg' ein zweites Gerät mit der gleichen IP an, und weise ihm das Model "generic" zu. Dann sollte alles ankommen.

Paul · 19 Januar 2021, 00:15:58

Sorry, aber so umständlich benötige ich es nicht. Die fehlende Daten hole ich mir über HTTPMOD und füge sie mir per userReadings ins Gerät. Dafür brauche ich kein Modul, wo ich dann ein Gerät doppelt anlegen muss.

Und wie sollte ich ein neues Gerät anmelden, er kennt es doch schon (so deute ich den Bildschirmausdruck)

Ich verstehe wirklich den Sinn dieses Moduls nicht.

gvzdus · 19 Januar 2021, 07:22:59

pah hat sich bei Mod_Shelly entschieden, einige Werte wie die Chiptemperatur in Celsius und Fahrenheit zu ignorieren. Gegen diese ästhetische Entscheidung möchte ich nicht besserwisserisch verstoßen.

Gleichzeitig haben wir das "generic"-Model aus der Taufe gehoben, das *alles* erhält. Damit sollte jedes sensorhafte Shelly-Gerät (Bewegungsmelder, Flood, Gas u.s.w.) unterstützt werden. Allerdings fehlt mir dazu Feedback.

Ein weiteres Shelly-Gerät kannst Du natürlich anlegen, indem Du "define zweitgeraet Shelly ip" absetzt, und dann dem Gerät das Model "generic" zuweist. Eine andere Möglichkeit, zu sehen, was gesendet wird, ist, auf "verbose 5" im Shelly-Monitor zu gehen - das wird aber geschwätzig im Logfile.

Natürlich kannst Du alternativ mit HTTPMOD pollen, aber das ist Engineeringaufwand und CPU-Overhead, und z.B. für Bewegungsmelder durch die Verzögerung nicht gefühlsecht.

MadMax-FHEM · 19 Januar 2021, 08:16:52

Ebenso "holt" ein userReadings am Shelly-Device die Daten vom HHTPMOD-Device ja auch nur, wenn es getriggert wird durch eine Änderung am Shelly-Device.

Und da es verm. kein "passendes Trigger Reading" dort gibt hast du verm. ein userReadings ohne expliziten Trigger was dann u.U. öfter (als nötig) "läuft" und verm
"veraltete" Daten holt.
Weil verm. HTTPMOD-Zyklus und userReadings-Trigger nie "zueinander passen"...

Aber niemand "zwingt" dich das zu nutzen...

Gruß, Joachim

bombardi · 19 Januar 2021, 09:58:05

Seit der Monitor bei mir läuft habe ich vorlaufend folgende Art von Meldungen im Logfile

Code Auswählen

2021.01.19 09:53:36 2: Defined real device XXXXXXXXX for 192.168.X.XX as model shelly2.5
2021.01.19 09:53:37 1: Panic, it happened: Cache for 192.168.X.XX did contain a none-hash

Wie kann ich das abstellen ?

bombardi · 19 Januar 2021, 10:01:17

Eine weitere Frage
Wie kann ich dafür Sorgen, das die Seite vom ShellyMonitor Device nicht andauernd refreshed wird.
Ich kann sonst keine Einstellungen am Device vornehmen (nicht mal den Raum ändern) weil vor Auswahl des Raumes schon ein Refresh durchgeführt wird.

bombardi · 19 Januar 2021, 10:06:21

Zitat von: gvzdus am 18 Januar 2021, 22:51:54
Hi Joachim,
Geräte, die nicht mehr da sind, sollten nach etwa 65 Minuten verschwinden. Die Multicast-Pakete enthalten eine TTL, im verbose 5-Log als "validity" aufgeführt werden. Die werte ich aus, und nach Ablauf sollte das Gerät in der Tabelle verschwinden:
Code Auswählen Erweitern
URI: /cit/s, global_devid = SHPLG-S#B86612#2, validity=3840, serial=57406

Das ist problematisch, z.B. für Floods und DW's, die sich eventuell nur alle 6 Stunden melden (bei mir im Normalfall erst nach 24 Stunden).
Besser wäre es dafür die Geräte zu markieren und dem Benutzer das Löschen zu überlassen, damit sie nicht immer erscheinen und verschwinden.

gvzdus · 19 Januar 2021, 10:09:47

Du hast das Szenario von Wetterhexe, was jetzt ohne Crash abgefangen wird.
Ich hatte es einmal auch bei mir und konnte es nicht reproduzieren. Die eine Bitte: Schalte ShellyMonitor auf "verbose 5" und schicke mir bitte eine Minute Logfile vor dem Crash. Da Anhänge per Pmail nicht gehen, vielleicht direkt an gvz Klammeraffe garnix.de .
Alternativ kann liebend gerne jemand einen Code-Review durchführen und mir um die Ohren hauen, wie ich in der Hash -> Array -> Hash - Welt mich verhaspelt habe und das Array einen String statt einer Hash-Referenz enthält. Ich vermute: Auf der IP, die in der Panic-Zeile aufgeführt wird, liegt ein reales und definiertes Device? So war es bei mir.

Das "ewige" Reload ist ein Folgefehler. Da laufend der Eintrag wieder weggemüllert und neu angelegt wird, ist nicht nach 30 Sekunden, wenn alle Geräte gefunden wurden, Ruhe.