39_CoIoT - Modul zur Interpretation der Multicast-Updates von Shellys

[MadMax-FHEM]

Nach dem gestrigen Frust habe ich heute nicht weiter gemacht.

Ohje...

Na dann mach doch mal ne Pause!

Aber Deine Frage will ich heute noch beantworten: Version 4 geht so vor: Bei "autocreate" wird vor dem Anlegen eines neuen Device geprüft, ob die (unveränderliche) Shelly-ID bei einem anderen Device existiert, und wenn ja, das Device auf die neue IP aktualisiert. Etwas übergriffig, aber fully DHCP-compatibel.

Danke.
Wieso "übergriffig"...
Genau das hatte ich mir gedacht bzw. "erwartet"...

Gruß, Joachim

[Prof. Dr. Peter Henning]

@MadMax-FHEM: Hmmmm - Ich habe doch nicht "losgepoltert" ? Du hast natürlich Recht mit der Einstellung des DHCP-Client, so mache ich es ja auch. Ich habe das oben präzisiert.

LG

pah

[gvzdus]

"Übergriffig", weil eine vom Benutzer festgelegte Konfiguration "besserwissend" überbügelt wird. Deswegen auch die Verknüpfung mit autocreate: Nach dem Motto, wenn "ich COIOT" eh' dafür zuständig bin, die Devices anzulegen, dann darf ich sie auch umkonfigurieren.

Mit etwas Abstand bin ich jetzt dazu gekommen, dass meine gesuchte Funktion, eine (ggf. größere) HTML-Tabelle im FHEMWEB-CoIoT-DeviceView zu rendern, geht:
Irgendwann fiel mir ein: "Hey, wie macht das eigentlich das SVG-Device?". Und jetzt habe ich FW_detailFn entdeckt.
Damit geht es ja wohl.

Der Kampf gegen die Referenzen auf Hashes mit referenzierten Arrays auf referenzierte Objekte kann also weitergehen. God bless America, und hoffentlich keine Meldungen über unblessed references im Logfile mehr...

[Prof. Dr. Peter Henning]

Wenn ich helfen kann, sag Bescheid.

LG

pah

[gvzdus]

Vielen Dank, der Kampf war zwar zäh, aber Du wärest vermutlich nicht darauf gekommen, mir den Tipp zu geben, dass mein Fehler in Sachen HTML die unschuldige Redefinition einer Variable mit "my" wäre... Jetzt klappt es auch mit HTML.

Stand der Dinge ist jetzt wieder dem Release entgegengehend.

TODO:

• ignoreDevice checken
• expiry von Devices, die sich nicht mehr melden
• LogLevel von Meldungen anpassen
• ??

Ich hänge das Modul diesmal hier direkt an, weil es im Vergleich zu V4 eher wackeliger als stabiler ist - dafür mal ein Screenshot, wie ich mir das so vorgestellt und umgesetzt habe. Die "fett grünen" Devices sind definiert, die kursiven werden beim "Create" angelegt.
Noch schöner wäre ein Popup mit einem Textfeld, was gleich fragt: "Willst Du nicht einen schöneren Namen als shelly_plug_s_7adea2 wählen?". Aber ob das im "Werkzeugkasten" für eine GUI so vorgesehen ist, ist mir unklar.

[rudolfkoenig]

Vorgesehen ist uebertrieben, aber im attrTemplate realisiert.

[MadMax-FHEM]

Naja, ein rename kann man vom Anweder schon noch "verlangen"

Da sind andere Module auch nicht "besser" und die meisten die ich so kenne nehmen auch "irgendeine" Device-ID zum "generieren" eines Namens...

Leider habe ich grad nur noch einen Shelly zum Testen

Die anderen sind verbaut und im "eigenen Netz", da klappt das ja mit dem "Finden" nicht so...

Aber mal sehen, vielleicht bestelle ich noch ein paar (ca. 2 könnte ich noch "brauchen" / dann ist aber gut mit Wifi-Dingern)...

Gruß, Joachim

[gvzdus]

Moin Joachim,

Ich will Dich nicht nötigen, im Produktionsnetz zu spielen. Bin glücklich, jetzt mein Testsystem auf einem weiteren Raspi hochgezogen zu haben, damit die Frau nicht immer gleich mit xy droht, wenn im Flur nicht das Licht angeht.

ABER:
Das Modul wertet Multicast aus. Multicast ist kein Broadcast, Multicast ist durchaus dafür vorgesehen, über einen Router hinweg weitergeleitet zu werden. Multicast ist normalerweise am DSL/Kabel-Modem gefiltert, weil Deine Shellys ihren Stand ja nicht weltweit teilen sollen. Ebenso auf Providerebene. Aber zwischen zwei Netzen daheim sollte es ein Setting am Router sein.

Viele Grüße, Georg

[MadMax-FHEM]

Ich weiß schon, dass das "nur" ein Setting im Gateway ist...

Aber was nicht hin und her muss, muss nicht hin und her

Evtl. kann ich ja zum Testen mal meinen Test-PI ins andere Netz umziehen...

Aber egal wie brauche ich erst mal wieder Zeit dafür...
...am WE ist Familie und ab Mo leider wieder Arbeit...

Da muss ich erst sehen, was da los ist

Gruß, Joachim

[gvzdus]

Ich bin jetzt eigentlich wieder da, wo ich mit Version 4 war: Scheint zu laufen.

In der Tabellenansicht kann man per Klick Devices anlegen, alternativ mit dem Befehl "set <coiot> autocreate <ip-pattern>".
Die Devices erhalten jetzt ggf. auch ein passendes webCmd-Attribut.

Die Erkenntnisse von Tim zum Shelly Duo sind eingearbeitet.

Das "AutoCreate" ist aber immer noch ohne Nutzung des Auto-Creates. Ich habe ca. 1 h recherchiert, und war eher verwirrt durch das Gefundene. FHEM ist halt kein Manual, was man durchliest, sondern Foren + Wiki + Rätseln. Einerseits ist die Beziehung COIOT zu Shelly-Modul ja das zweistufige Konzept, andererseits kommt das Shelly-Modul sehr gut auch ohne "mich" zurecht und benötigt kein Dispatching der Daten der physikalischen Schnittstelle.

Lieber Rudi, das mit dem "AutoCreate nach reiner Lehre" würde ich gerne noch umsetzen, weil die Vorteile so sind, wie ich FHEM kenne: Eine File-Log wird angelegt, u.s.w. Mir ist aber unklar, ob das "Kooperation" durch das Shelly-Modul voraussetzt, und wie ich das richtig auslöse ("Dispatch" ?). Darf ich da um die Aussage "Klappt auch mit Shelly-Modul as is" und "Guck mal Zeile xy im Modul z" bitten? Das ist ein vermutlich Zeit-Tausch-Verhältnis von weit über 1:10...

[rudolfkoenig]

Erst pruefen, ob die Instanz, was man anlegen will, noch nicht existiert. Ueblicherweise passiert das im ParseFn eines Moduls, was von Dispatch aufgerufen wurde, anhand Modul lokalen Daten ($modules{XX}{defptr} oder my %var).
Dann einen String basteln, was einem define entspricht, bloss statt define das Wort UNDEFFINED verwenden: "UNDEFINED FS20_$dev$btn FS20 $dev $btn"
Mit diesem String ein global Event generieren: DoTrigger("global", "UNDEFINED..."). Im ParseFn-Fall reicht diesen String zurueckzuliefern, DoTrigger uebernimmt Dispatch selbst.

autocreate hoert auf global:UNDEFINED.*, und wandelt es in CommandDefine um, setzt room, legt FileLog an, etc, all das kann der Benutzer aendern/unterbinden, bzw. das Zielmodul(!) ueber $modules{XX}{AutoCreate} beeinflussen.

Falls man weiteren Schabernack mit dem gerade angelegten Instanz treiben will, dann kann man z.Bsp per PrioQueue_add() oder InternalTimer(0,...) direkt vor DoTrigger (bzw. dem return in ParseFn) eine Funktion einhaengen, und hier die nachtraeglichen Aktionen ausfuehren. Beispiel dafuer siehe 10_MQTT2_DEVICE.pm

[gvzdus]

Vielen Dank, Schritt 1 klappt wunderbar.

Zum Schabernack, in meinem Fall mit "Attr": Im Code sieht das jetzt so aus und funktioniert:

Code Auswählen Erweitern

   
DoTrigger("global", "UNDEFINED $dname Shelly $ip");
CommandAttr ( undef, $dname . ' model ' . $model);
CommandAttr ( undef, $dname . ' interval 600' );


Was ist unethisch daran, einfach die "CommandAttr"s direkt hinterherzuwerfen, anstatt sie wie von Dir vorgeschlagen mit "PrioQueue_add() oder InternalTimer(0,...)" zu definieren?

[gvzdus]

Und, weil jetzt eigentlich nur noch das "Expiren" von Devices fehlt, die sich nicht mehr melden:

Zum Modulnamen:
pah hatte COIOT für gut befunden, oder "CUL_IP", wenn man höher zielt. Meine Alternativen finde ich selber nicht mehr gut.
COAP ist m.W. irreführend, weil ein Modul, dass nur eine ganz konkrete Herstellervariante spricht, nicht den Namen für sich reklamieren sollte.

Ich möchte noch den Namen "AutoShelly" in die Runde werfen. Oder "ShellyManager"? "ShellyCreate?"

Warum? Weil CoIoT eine Allterco-spezifische Bezeichnung ist, die bei quasi niemandem "etwas triggert". Ziel ist aber, dass ein Nutzer aus dem Namen halbwegs ableiten kann, dass es etwas mit der Hardware vor der Nase zu tun hat.

Meinungen?

[MadMax-FHEM]

Also ich bekomme demnächst noch 2 (oder 3) Shellys und einen "Test-Shelly" hab ich noch, werde also mal wieder "rumspielen" können...

Wie wäre Shelly-Monitor?

Shelly-Create klingt "eigenartig" und Shelly-Manager etwas "groß", wobei ich ja nicht weiß, was du mit dem Modul noch bor hast...

Gruß, Joachim

[gvzdus]

39_ShellyMonitor ist okay, gefällt mir besser als 39_COIOT.