welcher Controller merkt sich den letzten Wert bei Abschaltung

Begonnen von Muschelpuster, 20 April 2020, 09:19:54

Vorheriges Thema - Nächstes Thema

Muschelpuster

Moin zusammen,

wir renovieren gerade etwas und dabei soll auch unser Wohnzimmer weiter mit FHEM verbunden werden.
Ich habe 3-4 (vielleicht am Ende auch 5) Stellen, an denen ich 1-kanalige LED dimmen will. Nun möchte ich nicht überall die Netzteile und Controller 24/7 laufen haben und habe schon zu unserem Einzug vor 18 Jahren schaltbare Steckdosen in jede Ecke legen lassen.
Mein Gedanke ist daher nun, einen zentralen Homematic-Aktor zu haben, der 'in allen Ecken' die Stromversorgung einschaltet. Hier sollen dann die Dimmer den zuletzt eingestellten Wert wiedergeben und können dann neue Informationen empfangen.
Nun ist nur die Frage, was verträgt sich am Besten mit diesen Gedanken?

  • MiLight
    Da weiß ich, das meine Anforderungen funktionieren, denn da betreibe ich schon einige Controller relativ erfolgreich und zuverlässig. Auch der Preis spricht für MiLight, dagegen spricht etwas, dass hier ein neuer WiFi-Controller fällig ist, der dann wieder 24/7 am Netz hängt
  • LD382
    Preislich auch sehr interessant, jedoch zum Verhalten von dem Kollegen konnte ich recht wenig finden
  • LW12
    Deutlich teurer und ich habe auch keine Ahnung, wie dieser sich dieser mit meinem Ziel verträgt.
  • HM LC-dim1PWM-CV
    Der geht schon richtig in's Geld. Als Bausatz würde es gerade noch gehen, aber dann könnte ich mir auch was auf ESP-Basis zusammen braten. Durch den Rückkanal hätte ich ständig ausgefallene Geräte, gehe aber davon aus, dass auch 'offline' eingestellte Werte beim Einschalten übernommen würden. Aber was sagen die Funk-Limitierungen, wenn da die ganzen Geräte auf einen Schlag wieder da sind und sich komplett abgleichen. Habe ich dann meine Credits für die aktuelle Stunde aufgebraucht?

Da ich mir nun natürlich nicht erst einmal alle Optionen zum testen kaufen möchte, werfe ich die Frage mal hier in den Raum und hoffe auf das Schwarmwissen  ;)
Und vielleicht gibt es ja noch bessere Optionen, die ich überhaupt nicht auf dem Schirm habe...

planerische Grüße
Niels
fhem @ ZBOX mit 1,6MHz Celeron, 4GB RAM & 120GB SSD mit Debian Bullseye # MiLight # Homematic via CCU3 # W&T WebIO # Rademacher DuoFern # ESPeasy # logdb@mysql # configdb@mysql # Shelly @ MQTT2 # go-eCharger mit PV-Überschussladung via DOIF

TWART016

Hallo,

Shelly RGBW2 läuft über WLAN. Verbindung über Web oder MQTT.
Edit: über FHEM sollte man doch mitbekommen, wenn ein Gerät wird online ist.

Muschelpuster

Danke für die Anregung. Shelly hatte ich nach den ersten Meldungen über eine zweifelhafte Qualität aus den Augen verloren. Das liest sich ja inzwischen ganz nett. Da werde ich mich mal tiefer mit beschäftigen und kann auch gleich auf den geplanten Homematic-Aktor für das generelle Einschalten verzichten. Die Frage ist natürlich, wie schnell/langsam ein Shelly bootet, also bis das Licht nach Einschalten des Hauptschalters da ist. Da ist ja wieder MiLight durch seinen simplen Aufbau unschlagbar.
Klar bekommt FHEM mit, ob ein Gerät da ist oder nicht (ok, bei MQTT wohl eher nicht), aber das ist nicht die Frage. Wenn ich den Geräten zentral den Saft abdrehe ist ja nichts anderes zu erwarten ;-)

alternative Grüße
Niels
fhem @ ZBOX mit 1,6MHz Celeron, 4GB RAM & 120GB SSD mit Debian Bullseye # MiLight # Homematic via CCU3 # W&T WebIO # Rademacher DuoFern # ESPeasy # logdb@mysql # configdb@mysql # Shelly @ MQTT2 # go-eCharger mit PV-Überschussladung via DOIF

Beta-User

Kurze Anmerkugen dazu:

- MiLight: Na ja, könnte evtl. bei dir ok sein, ist ja ziemlich Platz  drumrum. Aber eine aktuelle Statusrückmeldung des Leuchtmittels bekommt man damit einfach nicht. Würde ich also eher auch für diesen Anwendungsfall verwerfen.

- MQTT: Wenn das Gerät "last will" sendet (Shelly-firmware tut das), bekommst du sofort Info, wenn das Ding wieder im Netz hängt, und nach Ablauf der angekündigten Frist (1,5 Min?) auch das "offline" vom Broker, wenn es nicht mehr dort ist. Einrichtung mit MQTT2-Modulen ist super-easy.

- Würde einen Blick auf ZigBee werfen. Ist zwar teuerer als Milight o. Shelly, und eigentlich auch besser "always onn" zu betreiben, aber man bekommt - je nach IO-Weg - irgendwann Meldung, wenn das Gerät wieder am Netz hängt. Dimmer gibt es mind. auch von DE und Paulmann (toom?), wobei ich bisher hier noch keine "Paulmann-Rückmeldung" gesehen habe. Aber generische Geräte wie Dimmer sollten eigentlich von fast jeder Lösung (insbesondere deCONZ und zigbee2mqtt) unterstützt werden...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Muschelpuster

Danke Beta-User,

nach meinen ersten Versuchen mit Zwave, die nicht so prall waren, habe ich auch mal nach zigbee als 'beseres' Zwave geschaut, das Ganze aber verworfen. Aktuell möchte ich nicht noch weitere Standards einführen. Dazu fehlt auch chronisch die Zeit.
Über die Anschaltung von IOT-Komponenten über WLAN kann man ja trefflich philosophieren, mir gefällt der Weg inzwischen, zumal meine Unifi-APs da eine gute Infrastruktur zur Verfügung stellen. Kritische Komponenten bekommen Internetverbot (z.B. MiLight) oder kommen gleich in's Gastnetz (z.B. FireTV). Ich werde nun mal ein IOT-WLAN in einem eigenen VLAN aufbauen, dann kann ich auch gleich das schon lange brach liegende Projekt mit erschlagen, meiner Fritte die Verwaltung des Gast-Netzes zu entziehen, denn da ist die ja so flexibel wie Krupp-Stahl.

reduzierte Grüße
Niels
fhem @ ZBOX mit 1,6MHz Celeron, 4GB RAM & 120GB SSD mit Debian Bullseye # MiLight # Homematic via CCU3 # W&T WebIO # Rademacher DuoFern # ESPeasy # logdb@mysql # configdb@mysql # Shelly @ MQTT2 # go-eCharger mit PV-Überschussladung via DOIF

Muschelpuster

So, das habe ich jetzt davon - ich habe mir wieder einen Virus eingefangen - den Shelly-Virus. Danke dafür  ;)
Der Einbau war zwar trotz der Bauform bei mir eine Herausforderung, da in den Dosen zu viele Kabel ankommen bzw. z.T. nur 40er Dosen verbaut sind und die Schalterprogramme auch für einen blöden Taster recht verschwenderisch mit dem Raum umgehen. Aber mit peniblen Aufräumen in den Dosen (nicht den 40ern) und einer Leerdose passt jetzt alles.
Zitat von: Beta-User am 21 April 2020, 09:42:39
...Einrichtung mit MQTT2-Modulen ist super-easy...
Ja, MQTT2 und der Shelly 1 waren erschreckend einfach, dafür passt das Template vom Dimmer nicht (mehr):
MQTT2_shellydimmer_D***** attr setList: more parameters needed
Unknown command dimup:noArg, try help.
Da werde ich mich jetzt mal mit vergnügen.

entschiedene Grüße
Niels
fhem @ ZBOX mit 1,6MHz Celeron, 4GB RAM & 120GB SSD mit Debian Bullseye # MiLight # Homematic via CCU3 # W&T WebIO # Rademacher DuoFern # ESPeasy # logdb@mysql # configdb@mysql # Shelly @ MQTT2 # go-eCharger mit PV-Überschussladung via DOIF

Beta-User

Thx. für den Hinweis. Da hatte eine Klammer gefehlt ( "{ " ) nach noArg, ist seit eben im svn gefixt.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Muschelpuster

Moin & Danke,

ich habe schon viel gelernt, war aber noch nicht so wirklich weiter. Ich habe mir jetzt mal die geänderten Dateien (httpmod.template & mqtt2.template) aus dem SVN gezogen, auf mein System kopiert und FHEM neu gestartet. Leider ist die Fehlermeldung beim set attrTemplate noch immer da. War das von mir zu simpel gedacht? Die Klammer ist da...
Ich habe das Device auch nochmal gelöscht und das mit dem frisch durch die nächste MQTT-Meldung angelegte Device getestet - ohne Erfolg.

einfache Grüße
Niels
fhem @ ZBOX mit 1,6MHz Celeron, 4GB RAM & 120GB SSD mit Debian Bullseye # MiLight # Homematic via CCU3 # W&T WebIO # Rademacher DuoFern # ESPeasy # logdb@mysql # configdb@mysql # Shelly @ MQTT2 # go-eCharger mit PV-Überschussladung via DOIF

Beta-User

Mist, hatte nur den Fehler _in_ der Zeile gesehen, nicht den _darüber_. Da war was reingerutscht, das da nix verloren hat... (Zeile 2006 alt). Nächste Iteration ist wieder im svn. Es müßte reichen, "{AttrTemplate_Initialize()}" aufzurufen, einen Neustart braucht es eigentlich nicht.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Muschelpuster

Super - funktioniert - Danke!

Zitat von: Beta-User am 26 April 2020, 12:53:11Es müßte reichen, "{AttrTemplate_Initialize()}" aufzurufen, einen Neustart braucht es eigentlich nicht.
Oh, ob ich mir das merken kann, ich fürchte/hoffe, dass ich das nicht so oft brauche  :-[
Aber ich weiß ja jetzt, wo ich nachlesen kann - wenn ich mir das merke  8)

getestete Grüße
Niels
fhem @ ZBOX mit 1,6MHz Celeron, 4GB RAM & 120GB SSD mit Debian Bullseye # MiLight # Homematic via CCU3 # W&T WebIO # Rademacher DuoFern # ESPeasy # logdb@mysql # configdb@mysql # Shelly @ MQTT2 # go-eCharger mit PV-Überschussladung via DOIF

Beta-User

Danke für die prompte Rückmeldung, dann kann ich das aus meiner "hat das funktioniert?"-Liste streichen... :)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors