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

[Wzut]

Ist es sinnvoll, dass die Geräte auch automatisch ein Room-Attribut bekommen?

machen viele Modul Autoren, so sind die Schäfchen in einem Stall und der unerfahrene User sucht sich keinen Wolf unter Everthing.

[rudolfkoenig]

machen viele Modul Autoren, so sind die Schäfchen in einem Stall und der unerfahrene User sucht sich keinen Wolf unter Everthing.

Wenn man das mit autocreate machen will, setzt man in Modul_Initiialize des Zielmoduls Folgendes:

Code Auswählen Erweitern

$hash->{AutoCreate} = { "devNameRegexp"=> { ATTR=> "room:myRoom group:myGroup" } };

[gvzdus]

Zunächst einmal @Joachim: Der Shelly 1L wird vermutlich am besten als Model "shelly1pm" eingetragen. Denn auch hier haben sie wieder Power-Metering, und pah hat den Shelly1 als Gerät ohne Powermetering definiert, den Shelly1PM als Gerät mit PM.

Vielleicht meldet er sich ja auch im Broadcast wie ein Shelly1PM, wir (Du) werden sehen...

@Rudi: Ich muss mich in das "AutoCreate" wie Du es meinst mal einlesen. Im Moment schieße ich einfach "CommandDefine"-Aufrufe los, habe ich mir von MQTT abgeguckt.

@Joachim: "Legt Geräte mit Poll-Intervall 600 an" meinte: "Während ohne Angabe das HTTP-Polling-Intervall der Shelly-Devices auf 60 Sekunden gestellt wird, legt COIOT die Devices mit 600 Sekunden HTTP-Polling-Intervall an". Angelegt werden die Geräte sofort, sofern "autoCreate" auf "Shelly" steht, sobald ein CoIoT-Paket reinkommt.
Dein Vorschlag gefällt mir, aber ich muss mal gucken, ob ich da eine simple Methode finde.

[gvzdus]

Ich habe jetzt gelesen, bin aber erst so mittelklug...

Joachims Wunsch "Nicht brutal alles anlegen, sondern Anzeigen und auf Klick anlegen" finde ich sinnvoll. Von der "Userstory" stelle ich mir das so vor: Man tippt das "define coiot COIOT", sieht zunächst den relativ leeren Screen des Devices, dann, mit jedem eintreffenden CoIoT-Paket nicht nur einen ansteigenden Counter, sondern eine sich aufbauende Tabelle:

Defined devices:

IP	Model	Name
192.168.0.10	shelly2.5 / roller	Kuechenrollladen

Undefined devices:

IP	Model	Create?
192.168.0.11	shelly2.5 / roller	Click to create
192.168.0.12	shelly2.5 / roller	Click to create

Das könnte man sich über ein devStateIcon basteln. Aber dann ist auch die ganze fette Tabelle in Everything & Co zu sehen. Ist die Umsetzung über devStateIcon FHEM-Mißbrauch oder von der Kunstfreiheit abgedeckt? Falls Mißbrauch: Was sollte ich lesen?

AutoCreate
Was ich so auf die Schnelle finde: Du, Rudi, hast Dir das 2-stufige Modulkonzept ausgedacht. So ganz unpassend ist es nicht. ABER: Mod_Shelly kommt von pah, Mod_Coiot von mir. Ich weiß nicht so recht, ob Dein autoCreate darauf passt. "Mein" autoCreate ist halt das direkte Abfeuern von CommandDefine und CommandAttr-Sequenzen. Ist das auch von der Kunstfreiheit abgedeckt, ober FHEM-Mißbrauch?

[MadMax-FHEM]

Das Modul HUEBridge hat auch ein eigenes? Autocreate für "Lampen"...

set HueBridge autocreate autocreateDevices (oder so ähnlich / müsste nachsehen)...
EDIT: Ob HueBridge "autocreate" nutzt oder "alles" selber macht weiß ich nicht...

Dabei werden auch alle noch nicht definierten Devices angelegt.
Wenn man welche nicht will, kann man die ja löschen.
Die werden dann zwar beim nächsten set autocreate wieder angelegt und "müssen" wieder gelöscht werden aber das wäre (für mich) auch i.O.

Liste mit Auswahl wär nat. superklasse

Gruß, Joachim

[gvzdus]

Dann warten wir mal auf das Urteil des Königs in Sachen Mißbrauch vs. Kunst.

Dann gibt es noch die wechselnde IP. Im Moment verhält sich das Modul ja so: Ist "autoCreate" ein, und stellt COIOT einen Wechsel der IP-Adresse anhand des von pah eingebauten Internals SHELLY-ID fest, dann wird das entsprechende Shelly-Device auf die neue IP um"defined" / ("defmod"ded). Bei autoCreate off zuckt COIOT mit den Schultern und verwirft das Paket.

Vorschlag:
Dieses Verhalten wird ein eigenes Attribut des COIOT-Moduls mit dem Namen "updateIpById 0:1". Default 1. Weil m.E. mehr Nutzen als Schaden.

[rudolfkoenig]

Kunstfreiheit: ich will keinem was verbieten, aber wir sollten, wenn moeglich, den Benutzer nicht immer wieder zwingen, was Neues zu lernen.

Autocreate ueberwacht "global:UNDEFINED deviceName deviceType define-Arguments", und ruft selber CommandDefine auf, legt ein FileLog an, und falls bekannt ein SVG, und setzt das room Attribut auf TYPE. All das kann der Benutzer aendern oder ausschalten.
Ich schlage vor, zunaechst das UNDEFINED Event zu generieren, und dann schauen, ob was fehlt.

Wg. Darstellung: ich wuerde auch erstmal mit dem set autocreate versuchen, das waere dann genauso wie beim HUE.
Optional mit weiterem Argument (Devicename oder *). Die Liste kann man kommagetrennt an set kleben, dann muss der Benutzer nichts tippen.
Wenn Du Tabelle bauen willst, dann am besten gleich wiederverwendbar

[Prof. Dr. Peter Henning]

Zum Thema autocreate: Hier sollte, ebenso wie bei der Weitergabe von Events, eine Ausschlussliste an Hand von speziellen Devicenamen UND an Hand des model-Attributes abgearbeitet werden. Ich möchte beispielsweise nicht, dass die ganzen einlaufenden Daten von meinen Shelly 2.5 Rollladenaktoren an diese in FHEM weitergereicht werden. Also z.B. als Attribute

excludeDevices <Liste>
excludeModels <Liste>

Zum Thema Tabelle: Solche anklickbaren Tabellen in der Detailansicht werden generiert von meinen Modulen 95_Alarm.pm, 95_Babble.pm, 95_PostMe.pm, 95_YAAHM.pm, 70_DoorPi.pm. Und nicht von mir: FritzBoxCallList.

Das ist zwar alles ziemlich speziell, und ob man daraus mit vertretbarem Aufwand etwas Wiederverwendbares machen kann, wage ich zu bezweifeln. Aber vielleicht kann man einfach etwas übernehmen.

LG

pah

[MadMax-FHEM]

So, dann kam doch glatt heute noch der Shelly1L:

Code Auswählen Erweitern


2021.01.05 18:10:29 5: URI: /cit/s, global_devid = SHSW-L#84CCA8ACBE60#2, validity=3840, serial=4


Ich habe mal beides ausprobiert, also shellypm und shelly1: geht beides.

Ja es gibt eine Leistungsmessung bzw. anders: es gibt Leistungswerte ABER: man kann auf der Webseite des Shelly angeben wieviel Leistung denn gezogen wird, wenn eingeschaltet ist und das wird dann angezeigt usw.

Also darauf kann ich verzichten...
...aber vielleicht wird das ja in zukünftigen FWs noch...

Wenn ich nich was tun/liefern kann: einfach Bescheid geben...
...allerdings werden die wohl demnächst auf das Hauptsystem ziehen und dort dann (erst mal) ohne CoIoT laufen...

Gruß, Joachim

[gvzdus]

Erst mal Danke, Joachim!

Eigentlich hatte ich gestern einen Plan für heute, bin aber vom Ziel weiter weg als mit der gestrigen Version.
Einerseits habe ich lange mit der Perl-Hölle der Referenzen auf Hashes in Array, die Referenzen sind, u.s.w. gekämpft, um auch nur das Modul ohne Crash laufen zu lassen.

Zum anderen hatte ich eigentlich einen Plan, was jetzt aus den 3 Inputs werden sollte:
Eine Tabelle in der Device-Ansicht, die alle aktiven IPs anzeigt, die zugehörigen definierten Module und die Geräte, die auf einen Klick zur Definition warten. Damit wollte ich eigentlich das "Paket-Zählen" ablösen, denn diese Tabelle braucht keine Updates (solange nichts passiert), und gibt trotzdem Feedback: "Hey, das ist bei Dir so da"

Allerdings gelingt es mir nicht, die "Kunstfreiheit" so weit zu treiben, dass aus dem State tatsächlich eine mehrzeilige Tabelle wird. Auch das PostIt-Beispiel funktioniert mit meiner ziemlich aktuellen FHEM-Version nicht wirklich - es gibt eine große leere Fläche in der ersten Zeile.

Ich muss mal gucken, wie ich morgen weiter mache, und ob irgendwas vom heutigen Code wiederverwendbar ist.

[MadMax-FHEM]

Hallo,

jetzt "muss" ich mich dann (doch) noch mal melden.

Ich habe heute einen Shelly in "sein" eigentliches Netz umgezogen: IoT-Netz eigenes V-LAN.

Dann ist nat. (erst mal) "essig" mit dem CoIoT.
EDIT: nat. den Shelly gelöscht und auch das CoIoT und dann CoIoT neu angelegt...

Ja ich weiß ich müsste nur mehr erlauben zwischen den Netzen, so wie bei den Google-Cast/Chrome-Cast Dingern (will ich aber eigentlich nicht).

Steuerbar ist er nat. mit dem Shelly-Modul (habe ihn manuell angelegt).

Wollte ich hier nur loswerden.
Obwohl verm. "bekannt" bzw. "erwartet"...

Wie wäre denn das Verhalten bei einem IP-Wechsel.
Also ich nehme ihn ins Netz -> DHCP vergibt Adresse -> CoIoT-Device findet ihn (und legt ihn an)
Dann vergebe ich (im DHCP) die eigentliche Adresse -> "reboot" dann mit neuer Adresse und dann?
(ja ich könnte vorher die MAC irgendwo rausfummeln [steht ja evtl. außen drauf?] und dann vorher schon eintragen / ich mache es aber [meist] andersrum)

Ja, könnte ich auch schnell testen, hab aber (leider) grad andere Dinge zu tun.

Gruß, Joachim

[Prof. Dr. Peter Henning]

(Edit) Es ist viel sinnvoller, die Adressen der Shellys _eben nicht_ variabel per DHCP zu setzen, sondern fest zu vergeben (per DHCP-Einstellung und/oder direkt im Device). Ich werde auch nicht davon abweichen, das über eine IP-Adresse statt über einen Hostnamen zu machen. Die normalen DNS-Anfragen sind nämlich _nicht_ Non-Blocking und können FHEM komplett ausbremsen.

LG

pah

[rudolfkoenig]

Die DNS-Anfragen sind nämlich _nicht_ Non-Blocking und können FHEM komplett ausbremsen.

Es sei denn, der Modulautor verwendet HttpUtils_gethostbyname() UND der Benutzer hat "global dnsServer" gesetzt

[MadMax-FHEM]

Es ist viel sinnvoller, die Adressen der Shellys _eben nicht_ per DHCP zu setzen, sondern fest zu vergeben. Ich werde auch nicht davon abweichen, das über eine IP-Adresse statt über einen Hostnamen zu machen. Die DNS-Anfragen sind nämlich _nicht_ Non-Blocking und können FHEM komplett ausbremsen.

LG

pah

Nicht gleich wieder lospoltern!

NIEMAND hat hier etwas von "HOSTNAME" geschrieben!

Und sehr wohl vergebe ICH meine (durchaus) festen IP-Adressen per DHCP!
(es gibt sowas wie: bitte lieber DHCP-Server, wenn diese MAC frägt, dann gib doch dem Client immer diese IP   )

Und das ist ein ganz normales Szenario und hat nichts mit dem Shelly-Modul zu tun!

Denn selbst wenn ich die IP fix im Shelly einstelle: er muss ja auch dazu erst mal ins Netz...

Ich wollte lediglich HIER (CoIoT!) loswerden, dass es eben (ohne weitere "Massnahmen") nicht zwischen V-LANs geht und einfach nur fragen was denn die "Strategie" ist (seitens CoIoT!!) wenn sich die IP ändert.

Nur als Frage.
Mir aber nicht so wichtig, weil ich kann es ja auch einfach ausprobieren was passiert...

Und entweder hier teilen was passiert ist (falls es interessiert) oder für mich behalten (wenn es niemanden interessiert)...

Gruß, Joachim

[gvzdus]

Nach dem gestrigen Frust habe ich heute nicht weiter gemacht. 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.