Modul 36_ShellyMonitor

enno · 19 Januar 2021, 16:26:37

ok, das Wasser ist aufgewischt und es wurde wärmer

das Thermometer hat sich gemeldet:

Internals:
   CFGFN      
   DEF        192.168.179.174
   DURATION   0
   FUUID      6006de9b-f33f-9270-99d9-c8c7cec47880e1e4
   INTERVAL   60
   NAME       Thermo_DG_DB_Shelly
   NR         17992
   SHELLYID   E0143E
   STATE      T: 19.88 °C H: 47.5 % B: 100
   TCPIP      192.168.179.174
   TYPE       Shelly
   Helper:
     DBLOG:
       dewpoint:
         MYSQL:
           TIME       1611069439.42282
           VALUE      10.23
       humidity:
         MYSQL:
           TIME       1611069439.42282
           VALUE      47.5
       network:
         MYSQL:
           TIME       1611062939.47264
           VALUE      <html>connected to <a href="http://192.168.179.175">192.168.179.175</a></html>
       state:
         MYSQL:
           TIME       1611062939.47264
           VALUE      initialized
       temperature:
         MYSQL:
           TIME       1611069439.42282
           VALUE      19.88
   READINGS:
     2021-01-19 15:43:04   battery         100
     2021-01-19 16:06:07   cfgChanged      0
     2021-01-19 15:34:21   cloud           disabled
     2021-01-19 16:17:19   dewpoint        10.23
     2021-01-19 16:17:19   extTemp_0       19.88
     2021-01-19 16:17:19   extTemp_0f      67.78
     2021-01-19 15:54:12   firmware        v1.9.0
     2021-01-19 16:17:19   humidity        47.5
     2021-01-19 16:20:26   network         not connected
     2021-01-19 15:43:04   sensorError     0
     2021-01-19 16:20:26   state           Error
     2021-01-19 16:20:26   temperature     19.88
     2021-01-19 16:11:00   wakeupEvent     sensor
Attributes:
   DbLogExclude .*
   DbLogInclude humidity,temperature,dewpoint
   event-on-change-reading humidity,temperature,dewpoint,battery,extTemp_0,
   icon       temperature_humidity
   interval   0
   model      generic
   room       71 Thermometer,Shelly
   stateFormat T: extTemp_0 °C H: humidity % B: battery
   userReadings dewpoint:extTemp_0.* {urDewpoint($name)},temperature { ReadingsVal("Thermo_DG_DB_Shelly","extTemp_0",0) }

Sieht soweit ganz gut aus. Ich habe MQTT dafür abgestellt und schaue mal ob die Daten weiterhin über dein Modul kommen.

Gruss
Enno

Jamo · 19 Januar 2021, 18:22:14

ZitatWarte bis Morgen 8 Uhr oder nimm die Version ein paar Beiträge oben und spiele sie per Hand ein!

Yep, mit der Version von weiter oben ist die Meldung weg. DANKE! ! !

gvzdus · 19 Januar 2021, 18:36:05

Die "morgen 8 Uhr"-Version ist also wärmstens zu empfehlen

In der Tabelle werde ich ab morgen noch bei "generic" den Device-Namen anführen, mit dem sich das Gerät meldet, z.B. SHPLG-S für Shelly Plug S. Mit diesem Namen erkenne ich die verschiedenen Geräte und weise ihnen Models zu. Hier wäre interessant, noch die Werte für Thermometer und Flood zu kennen, damit ich sie dokumentieren kann (Sieht man zwar auch am Verbose-Level 4 im Logfile, aber das kann man ja niemandem zumuten).

Sonst noch Wünsche / Ideen?

enno · 19 Januar 2021, 19:32:12

Zitat von: gvzdus am 19 Januar 2021, 18:36:05Hier wäre interessant, noch die Werte für Thermometer und Flood zu kennen, damit ich sie dokumentieren kann (Sieht man zwar auch am Verbose-Level 4 im Logfile, aber das kann man ja niemandem zumuten)

Flood bei mir SHWT-1
Thermo bei mir SHHT-1

Gruss
Enno

gvzdus · 19 Januar 2021, 22:52:10

Danke, die "generic names" sind dann ab morgen:

"SHWT-1" => "shelly_flood",
"SHHT-1" => "shelly_ht"

bombardi · 20 Januar 2021, 08:55:21

Nach Update läufts weiter gut.

Ich habe noch eine Frage zum Autocreate.
Ist es möglich, das nachdem die gewünschten Namen für neue Devices in der Tabelle eingetragen wurden diese dann auch bei Autocreate verwendet werden ?
Momentan habe ich versucht meinen Wunschnamen für das Device einzutragen und dann auf Autocreate gedrückt und es wurde der generische Name verwendet.
Bei Create wird ja der geänderte Name genommen.(habe ich jetzt nicht nochmal probiert)
Damit würde man das Rename nach dem Autocreate sparen.

gvzdus · 20 Januar 2021, 09:09:07

Wenn Du Dir die Diskussion im CoIoT-Thread (als Vorläufer zum jetztigen Namen "ShellyMonitor" anguckst), siehst Du, dass da etwas Konfusion ist.
"autocreate" war ursprünglich ein Attribut im Sinne des Betriebsmodus von ShellyMonitor. Die Überlegung: Wenn ein Device auftaucht, wird es automatisch unter dem generischen Namen angelegt - wie bei MQTT. Und es greift wiederum auf das autocreate-Modul von Rudi zurück.
"create" kam dann später, zusammen mit der Tabelle, im Sinne eines interaktiven ("Klick") und imperativen Befehls - unabhängig von den autocreate-Einstellungen.

Da ist zugegeben verwirrende Redundanz schon jetzt im Modul, die Dich dazu bringt, in der Tabelle was einzugeben und unten ein Set-Kommando anzuklicken - es hat nichts miteinander zu tun.

Ich würde vorschlagen: "autocreate" wird wieder ein Attribut, und wenn es (aktiv) eingeschaltet wurde, werden die Geräte automatisch generisch angelegt - sonst über die Tabelle mit Klick.

bombardi · 20 Januar 2021, 09:36:07

Ich denke dein Vorschlag ist besser als das verwirrende Verhalten, welches jetzt nicht sehr intuitiv ist.
Ich hatte sogar zunächst versucht autocreate auf 1 zu setzen und mich gewundert, das die Devices nicht automatisch erzeugt werden.

JWRu · 20 Januar 2021, 10:18:11

Gibt es einen Grund, warum nicht einfach das globale ,,autocreate" genutzt wird?

gvzdus · 20 Januar 2021, 10:22:12

Daran ist Joachim schuld!!

Joachim hatte im "autocreate"-Modul das autocreate abgeschaltet, und dann beim Klicken nichts bekommen, weil das autocreate im Sande verlief!
Damit sind 30% aller Nutzer gescheitert, und ich habe das Verhalten geändert.

Mal ein Plan:
- "autocreate" wird ein Attribut, macht ggf. autocreate völlig auto über autocreate
- "Create"-Klick (alternativ: "set <name> create <ip> <name>") legt das Gerät über "autocreate" an. Wenn autocreate nicht funktioniert, weil Joachim es abgeschaltet hat: Fehlermeldung.

MadMax-FHEM · 20 Januar 2021, 10:59:55

Ohje, was hab ich da (durch meine "Dummheit") angerichtet...

Gruß, Joachim

JWRu · 20 Januar 2021, 11:56:28

ZitatJoachim hatte im "autocreate"-Modul das autocreate abgeschaltet

Auch ich habe grundsätzlich autocreate abgeschaltet. Man kriegt ja sonst irgendwelche Geräte aus der näheren Umgebung angelegt.
Wenn ich ein neues Gerät hinzufügen möchte, schalte ich es kurzzeitig ein.

rudolfkoenig · 20 Januar 2021, 12:14:07

ZitatAuch ich habe grundsätzlich autocreate abgeschaltet. Man kriegt ja sonst irgendwelche Geräte aus der näheren Umgebung angelegt.

Ich empfehle fuer solche Faelle das neu angelegte Geraet per ignore Attribut zu verstecken. Die FHEM-Systemlast duerfte ohne autocreate hoeher sein, weil in diesem Fall fuer jede, von diesen Geraeten empfangene Nachricht, ein "global UNDEFINED" Event generiert wird.

gvzdus · 20 Januar 2021, 13:23:48

Ich weiß jetzt nicht, wo die Diskussion geführt werden sollte, aber gerne hier:

Ich habe bei FHEM mit MAX angefangen, und ohne zu wissen, was da passiert, habe ich es als gottgegeben angenommen, dass ein MAX-Gerät bei mir plötzlich auftaucht, einen Sch.-Namen hat, ein FileLog, und in einem Raum ist. Ich habe mich viel später eingelesen, dass ich verhindern kann, dass die Geräte von meinem Nachbarn bei mir auftauchen.

Die gleiche User-Experience hatte ich mit MQTT: Sch.-Name, aber wenn man was neu eingebunden hat, sucht man das neu kreierte Device, weiß nicht, ob man es umbenennen darf, vergibt sicherheitshalber einen Alias. Richtig nett fand ich, als ich bei MQTT das erste Mal durch Popups durch Fragen nach Attributen - sogar mit alexaName - durchgeführt wurde.

Das alles ist "autocreate", und eigentlich wäre also die autocreate-Logik in Mod_ShellyMonitor konsistent zur sonstigen FHEM-Erfahrung.

Aber andererseits bin ich da einen Schritt weiter Richtung DAU gegangen: Nämlich mit der Liste: "Hey, dass hier habe ich gefunden: Wähle einen Namen, und dann geht es los". Diese User-Experience könnte / sollte / hätte aber eigentlich modul-übergreifend da sein: Ein Spezial-Room "New kids in town", in dem alles auftaucht, was neu ist und von dem FHEM der Meinung ist: "Klick hier, gib einen Namen und ggf. noch Attribut xy ein - dann definieren wir das!". Da könnte z.B. eine über UPnP-Broadcasts erkannte Hue-Bridge zu gehören, oder die MÄXchen, oder MQTT-Clients, oder eben von Shelly-Monitor erkannte Shellies. Und natürlich das, was an den USB-Ports eindeutig zugewiesen werden kann.

Ich bin doch vermutlich nicht der Erste, der diese Idee hat, oder?

JWRu · 20 Januar 2021, 14:11:08

ZitatDie FHEM-Systemlast duerfte ohne autocreate hoeher sein,

Vielen Dank für die Info - das war mir nicht bewusst.
Da muss man ja auch mal drauf kommen, dass die Systemlast steigt, wenn man eine Funktion abschaltet.
Ich lasse es aber trotzdem ausgeschaltet, da meine ZBox mit FHEM eh unterfordert ist und ich keine Lust habe, mein System jedesmal anzufassen,
wenn irgendein Nachbar sich einen neuen Sensor gekauft hat.