Überarbeitung "Systemübersicht"

Begonnen von Beta-User, 24 Juni 2019, 14:49:59

Vorheriges Thema - Nächstes Thema

Beta-User

 :) ... die Qual der Wahl...

Das etwas größere "(fhem.pl)"@4_5 finde ich besser, das hebt die Sonderstellung dieser Datei mehr raus.

Auf die Schnelle sind mir jetzt noch 2 Kleinigkeiten aufgefallen:

- "Sensor or Actuators" => (einheitlich Ein- oder Mehrzahl) => "Sensors or Actuators" (man wird ja in der Regel mehrere haben...); da es Mischformen gibt, würde ich im Moment sogar dazu tendieren, entweder einen Querstrich statt or zu setzen, oder ein einfaches "&".... So machen wir es: "Sensors & Actuators".
- Die (Text-) Ausrichtung von HUEBridge und MQTT2_SERVER ist (@IO) jeweils nicht ganz mittig in der Box (ok, ist in 4_5 schon/noch ziemlich gefixt, sehe ich grade...)

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

DasQ

wenn wir hier fertig werden, soll ich die ganzen entwürfe hier im thread löschen?
Fhem on MacMini/Ubuntu.
Absoluter Befürworter der Konsequenten-Kleinschreibung https://de.wikipedia.org/wiki/Kleinschreibung
Infos zu Klimawandel http://www.globalcarbonatlas.org

Beta-User

Hmm, weiß nicht...
Damit verlieren halt die ganzen Anmerkungen ihren Bezugspunkt, aber eigentlich finde ich das nicht weiter schlimm. Andererseits kursiert dann auch nichts "falsches" mehr => tendenziell ja, löschen.

Lädst du die 4_7 ins wiki? (als neue Version am alten Ort, bitte)
Dann paß' ich bei Gelegenheit den Text weiter an...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

DasQ

DONE

über grösse und plazierung könnte man nochmals drüberschaun.
Fhem on MacMini/Ubuntu.
Absoluter Befürworter der Konsequenten-Kleinschreibung https://de.wikipedia.org/wiki/Kleinschreibung
Infos zu Klimawandel http://www.globalcarbonatlas.org

Beta-User

Thx!

Das mit Größe und Platz ist gar nicht so easy... Ohne thumb bekommt man es nicht so toll vergrößert, mit muß es mittig sein, sonst gibt es einen Umlauf...

Hat da jemand eine Idee? (Gallery?)

Ansonsten bin ich mal "auf dei Schnelle" über den Artikel drüber und habe das eine oder andere angepaßt. Wer mag, darf kritisieren, aber an sich will ich auch erst nochmal in Ruhe den Thread hier durchgehen, was da schon alles angerissen war und das dann möglichst auch abarbeiten, bevor ihr richtig loslegen dürft ::) . Bisher bin ich auch der Versuchung widerstanden, manches in Fußnoten zu verbannen (HM-CFG-USB, z.B., und manches andere rund um Homematic). Aber eigentlich fände ich das an der einen oder anderen Stelle nicht ganz verkehrt...

Bevor ich das vergesse: Ideen/Anregungen wg. des FLOORPLAN-Themas???
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Hallo zusammen,

meine aktuelle Stichwortliste:
ZitatWolke: Sprachsteuerung, weitere Erläuterung...
FLOORPLAN: wie damit umgehen?
ZWDongle/ZWave als Prototyp/"*ZWDongle/ZWave: showcase for other bidirectional systems"
Wo finde ich was? WAS kann FHEM WIE WOMIT... ("FHEM kann alles")
pgm2 - zu technisch/veraltet?
Homebrew... Nanocul usw ,Bastelecke

In dem Zusammenhang:
- Sprachsteuerung (m.E. als Teil der Wolke) taucht bisher gar nicht auf. Tendiere dazu, das (als Stichwort "voice control" in die Wolke aufzunehmen)?
- Irgendwie ist uns das prototypische bei ZWave verloren gegangen. Wenn wir die Grafik nochmal anfassen, sollten wir in den beiden Boxen m.e. das "e.g. " ergänzen...

Wer gerne noch was auf der Stichwortliste hätte: Bitte melden...


Aus aktuellem Anlaß habe ich auch einige Technologien (MAX! war der Anlaß) als "** evtl. nur noch gebraucht erhältlich" gekennzeichnet. Wer da noch Kandidaten hat: s.o.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Mal wieder ein Zwischenstand, nachdem ich etwas an dem Artikel weitergebastelt habe...

Eingang hat jetzt gefunden:
- Wolke: Sprachsteuerung, weitere Erläuterung... als neuer Abschnitt zu "Intra-/Internet"
- Den Abschnitt "Interfaces" habe ich in Richtung "ZWDongle/ZWave als Prototyp..." umgebaut, das ist jetzt auch etwas weniger HM-lastig und eher in Richtung "Viele Wege führen..." geworden. (Die Grafik könnte man trotzdem mit einem "e.g." versehen und bei der Gelegenheit noch "voice control" in die Wolke schreiben)
- Eine Hinweisbox zu "FHEM kann alles" ist dazugekommen

Im Moment finde ich diese Teile eigentlich schon ganz ok, der Artikel sollte m.E. weiter einigermaßen kurz bleiben, daher würde ich "Wo finde ich was? WAS kann FHEM WIE WOMIT..." eher nicht weiter vertiefen?

Offen wäre damit noch:
- pgm2 - zu technisch/veraltet?
- FLOORPLAN: wie damit umgehen?
- Homebrew... Nanocul usw ,Bastelecke

Zum letzten Punkt habe ich momentan keine rechte Idee, wie das in den Artikel passen könnte und neige zum Weglassen, bei den anderen beiden wäre ich weiter für Meinungen dankbar, wie das "allgemein" gesehen wird...

Grüße, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

PeMue

Hallo Beta-User,

Zitat von: Beta-User am 02 September 2019, 12:12:11
Mal wieder ein Zwischenstand, nachdem ich etwas an dem Artikel weitergebastelt habe...
ich habe mir den Artikel mal durchgesehen, ist m.E. sehr gut verständlich. Ich habe noch ein paar Hinweise/Fragen:
- LAN fehlt in der Grafik komplett, d.h. man könnte z.B. eine HM-MOD-RPI-PCB über einen USR-K an das LAN hängen (Spezialfall)?
  Oder ist das der Doppelpfeil bei External Soft-/Hardware?
- Grafik: die CCU3 kann HM bzw, HM-IP, daher die beiden verschiedenen grünen Farben?
- Grafik: das MySensors Gateway fehlt, mit aufnehmen?
- Im Text: der JeeLink kann m.E. nur 868 MHz, 433 MHz Protokolle (die sich von den 868 MHz Protokollen unterscheiden) sind nicht implementiert.

Zitat von: Beta-User am 02 September 2019, 12:12:11
Im Moment finde ich diese Teile eigentlich schon ganz ok, der Artikel sollte m.E. weiter einigermaßen kurz bleiben, daher würde ich "Wo finde ich was? WAS kann FHEM WIE WOMIT ..." eher nicht weiter vertiefen?
Offen wäre damit noch:
- Homebrew ... Nanocul usw., Bastelecke

Zum letzten Punkt habe ich momentan keine rechte Idee, wie das in den Artikel passen könnte und neige zum Weglassen, bei den anderen beiden wäre ich weiter für Meinungen dankbar, wie das "allgemein" gesehen wird...
Da würde ich keine eigene Kategorie im Bild spendieren. Homebrew ist halt Homematic im Eigenbau (ggf. mit erweiterten Funktionen, Big-Fixen, (noch) nicht implementieren ePaper Displays, usw.).
Ggf. könnte man im Text unter Interfaces beim JeeLink das LacrosseGateWay noch als Interface mit aufnehmen (gibt es auch nur hier  :)).
Dito für den immer populärer werdenden mapleCUx (Stichwort "eierlegende Wollmiilchsau"  ;D).
Wenn Du magst, mache ich die Korrekturen inkl. Verlinkung. Dito für die diversen Modulationsarten, die noch offen sind. Bei Protokollen würde ich die EC3000 mit aufnehmen.

Zitat von: Beta-User am 02 September 2019, 12:12:11
... daher würde ich "Wo finde ich was? WAS kann FHEM WIE WOMIT ..." eher nicht weiter vertiefen?
Beim zweiten Lesen meiner Antwort, ist mir noch ein Gedanke gekommen. Aus Anwendersicht ist die Systemstruktur ggf. gar nicht so wichtig. Er will vielmehr wissen, was brauche ich, wenn ich z.B.
- die Heizung im Zimmer (inkl. Fenster) überwachen/steuern will
- die Solaranlage/Heizung/... überwachen will (inkl. Urlaubsassistent)
- die Lichter steuern will (mit Sprachsteuerung, Anwesenheitserkennung, etc.)
- usw.
Wäre das nicht ein Ansatz, die verschiedenen HowTos mittels übergeordneter Kategorien zu sortieren/strukturieren? Es kann aber sein, dass ich gerade über das Ziel hinausschieße, dann bremst mich bitte :P


Gruß Peter
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

Beta-User

Hi Peter,

Danke für deine (überwiegend positiven) Anmerkungen, ich versuch's mal in der Reihenfolge zu beantworten:

Zitat von: PeMue am 02 September 2019, 17:08:35
- LAN fehlt in der Grafik komplett, d.h. man könnte z.B. eine HM-MOD-RPI-PCB über einen USR-K an das LAN hängen (Spezialfall)?
Oder ist das der Doppelpfeil bei External Soft-/Hardware?
(Vorab: auf der Grafik ist eigentlich schon too much... Erweiterungen daher bitte nur, wenn das "zwingend" ist ;D .)

Ansonsten ist "LAN" zwar ein Stichwort, mit dem der geneigte Leser (in dem Fall gedanklich...) irgendwas verbindet, aber die Frage ist, auf was wir die Gedanken dann leiten wollen? Im Fall des USR-K ist bedauerlich, dass den so wenige kennen, aber für die Darstellung auf der Grafik reicht das m.E. nicht als Argument - genausowenig wie die viel bekannteren Varianten HM-MOD-RPI-PCB+(MapleCUN|ESP8266) was auf der Grafik zu suchen haben (mMn.)...
Vielleicht wäre es eine Idee, im Text unten bei dem Modul den Hinweis anzubringen, dass man das nicht nur an den PI-GPIO betreiben kann? (Der Rest steht m.E. hier und sollte dort (bzw. den weiteren Links dort) ggf. verbessert werden: https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Verwendung_mit_anderer_Hardware.

Da es eigentlich eine mit einem "dummen" Netzwerkgerät verlängerte serielle Verbindung ist, ist das in den Kategorien, die wir irgendwann in der Vergangenheit hier mal diskutiert hatten keine "External"-Sache, sondern eher ein "dummes" Ersatz-Interface statt USB/GPIO-seriell ::) .
Zitat- Grafik: die CCU3 kann HM bzw, HM-IP, daher die beiden verschiedenen grünen Farben?
Yup! (Scheint einleuchtend zu sein... :) )
Zitat- Grafik: das MySensors Gateway fehlt, mit aufnehmen?
Eher den ZWave-Teil mit "e.g." belabeln, MySensors ist "nur" - wie EnOcean, das auch (mit Absicht, s.o.) fehlt - ein weiterer Vertreter eines "2-stufigen Moduls".

Zitat
- Im Text: der JeeLink kann m.E. nur 868 MHz, 433 MHz Protokolle (die sich von den 868 MHz Protokollen unterscheiden) sind nicht implementiert.
Da würde ich keine eigene Kategorie im Bild spendieren. Homebrew ist halt Homematic im Eigenbau (ggf. mit erweiterten Funktionen, Big-Fixen, (noch) nicht implementieren ePaper Displays, usw.).
Ggf. könnte man im Text unter Interfaces beim JeeLink das LacrosseGateWay noch als Interface mit aufnehmen (gibt es auch nur hier .
Dito für den immer populärer werdenden mapleCUx (Stichwort "eierlegende Wollmiilchsau"  ;D ).
Wenn Du magst, mache ich die Korrekturen inkl. Verlinkung. Dito für die diversen Modulationsarten, die noch offen sind. Bei Protokollen würde ich die EC3000 mit aufnehmen.
Entsprechende Klarstellungen und Ergänzungen im Text von Leuten, die wissen, was sie schreiben, sind jederzeit willkommen :) . Ich habe immer "Bauchschmerzen", wenn ich - zwangsläufig - über Dinge schreibe, die ich nicht (wirklich) kenne...
Homebrew könnte z.B. zumindest in die Bemerkungen bei HomeMatic rein?

(dto. für die Wired-Variante, und wo ich das lese: gab es nicht auch die simple (und bessere...!) Option, einen "ganz einfachen" RS485-USB-Stick als IO dafür zu verwenden...?!?)

Zitat
Beim zweiten Lesen meiner Antwort, ist mir noch ein Gedanke gekommen. Aus Anwendersicht ist die Systemstruktur ggf. gar nicht so wichtig. Er will vielmehr wissen, was brauche ich, wenn ich z.B.
- die Heizung im Zimmer (inkl. Fenster) überwachen/steuern will
- die Solaranlage/Heizung/... überwachen will (inkl. Urlaubsassistent)
- die Lichter steuern will (mit Sprachsteuerung, Anwesenheitserkennung, etc.)
- usw.
Wäre das nicht ein Ansatz, die verschiedenen HowTos mittels übergeordneter Kategorien zu sortieren/strukturieren? Es kann aber sein, dass ich gerade über das Ziel hinausschieße, dann bremst mich bitte :P
Uhhh, noch eine Baustelle...
Grundsätzlich gebe ich dir in zwei Punkten recht:
- Zum einen ist sowas wie dieser Artikel eher was Leute wie mich, die erst mal ein bisschen Theorie - hier eben Begriffskategorien - bzw. einen systematischen Überblick brauchen, bevor sie was kapieren.
- Leute, die eher den praktischen Angang haben und sich Theorie nebenher beim Nachvollziehen von Lösungen aneignen, wäre eine redaktionelle Aufarbeitung dieser doch schon ziemlich langen Liste hilfreich.

K.A., ob das allgemein bekannt ist, ich bin jedenfalls neulich darüber gestolpert, dass man die Einordnung der Artikel in die Kategorienseite beeinflussen kann, indem man das Schlagwort mit angibt, unter dem etwas einzusortieren ist. Hier das Beispiel, wie das in https://wiki.fhem.de/wiki/MQTT gelöst ist. Damit wird der Artikel auf der Kategorienseite ganz am Anfang und dann unter "E" wie "MQTT Einführung" angezeigt (auch noch kursiv...):
[[Kategorie:MQTT|Einführung]]
[[Kategorie:MQTT| ]]

Dann sollte man sich aber ggf. vorab ein paar Gedanken machen, wie die Struktur da aussehen sollte, der Rest wäre Fleißarbeit (und gesonder zu diskutieren?)...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Prof. Dr. Peter Henning

Kleiner Korrekturwunsch: Viele haben ihre Zigbee-Geräte über den deConz-Server und die Interfaces von Dresden Elektronik angeschlossen. Das bewegt sich dann auf demselben Niveau wie die Huebridge. Im Kasten sollte also (wie bei HomeMatic) stehen ZigBee und darunter in Klammern (Huebridge, RaspBee).

LG

pah

Beta-User

Mit "Kasten" meinst du die Grafik ganz oben?

Wenn ja: Inhaltlich ist das auch bei deCONZ das HUEBridge-Modul, das paßt eigentlich, zumal ja auch rechts dann der Hinweis steht, dass des weitere Optionen gibt. "An sich" könnte man da noch ein paar weitere reinpacken (tradfri-Bridge, und von/für Xiaomi gibt es auch was (?)). Was dann aber nicht mehr recht in das Schema paßt, ist zigbee2mqtt, hmmm...?
Neige dazu, das (bei der Grafik) so zu lassen, aber wenn noch mehrere der Ansicht sind, das wäre sinnvoll, ist das auch iO. (vorausgesetzt, @DasQ hat Lust, das umzusetzen).

Allerdings finde ich die Anregung völlig berechtigt, ZigBee an anderen Stellen im Artikel etwas mehr zu promoten. Das hat sich in den letzten Monaten dank IKEA, Aldi &Xiaomi von einer teuren Lösung weniger Hersteller hin zur echten Massenware entwickelt. In der Protokolle-Tabelle habe ich da schon etwas gebastelt und bin am überlegen, ob und ggf. wie das Thema bei Interfaces einen guten Platz haben könnte.
Der reinen Lehre nach wäre das aber dann wieder eine konkrete Hardware...? Dann den ConBee II vorneweg noch vor CUL?!? Dahinter dann den Hinweis auf Hardware-Alternativen?

Muß ich mal sacken lassen, vielleicht hast du oder sonst jemand eine Idee?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Prof. Dr. Peter Henning

Meine neues FHEM-Grundlagenbuch erscheint in 2 Wochen - da habe ich den Hardware-Teil bewusst kurz gehalten. Ein wichtiger Beitrag darin sind aber die Shelly-Aktoren, weil sie eben ohne Zusatzhardware auskommen, einfach im WLAN eingebunden sind, und auch nicht nur über MQTT funktionieren.

Dieser Pfad - IP-basierte Devices mit dezidierten Modulen ebenso wie HTTPMOD - fehlen in dem Diagramm komplett.

LG

pah

Beta-User

Zitat von: Prof. Dr. Peter Henning am 11 September 2019, 20:44:25
Dieser Pfad - IP-basierte Devices mit dezidierten Modulen ebenso wie HTTPMOD - fehlen in dem Diagramm komplett.
Hmm, der Hinweis ist berechtigt (betr. auf die Schnelle z.B. auch ESPEasy) :( .

Damit stehen wir wieder vor der Frage, ob "noch was" auf die Grafik muß.

Bin geneigt, das doch zu machen, weil auch noch ein paar andere Kleinigkeiten offen sind.

Würde dann die Ausbuchtung, in der heute nur der MQTT2_SERVER steht etwas vergrößern wollen, da "IP-based" drüberschreiben und dann darunter noch eine Box mit "native IP based \ (e.g. HTTPMOD, Shelly, ESPEasy)" einfügen, dazu korrespondierend auf der "Sensors&Actuators"-Schiene noch einen "Box-Stapel" mit "Shelly, ESPEasy,..."?

@DasQ: Ginge das, ohne dass du komplett von vorne anfangen müßtest? Oder gibt es andere Lösungen, bei denen z.B. nicht alles gleich sichtbar wäre (ich habe dazu noch keine konkrete Idee...).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Wernieman

#73
Selly/ESP8266 etc. finde ich eigentlich auch sehr wichtig.

Aber genau aus den Gründen hatte ich am Anfang gesagt, das ersichtlich sein muß, das noch vieiel mehr geht. Im Diagramm sollten wirklich "nur" die Wichtigsten Sein. Sonst wird es unübersichtlich
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Beta-User

Na ja, mMn. ist es ziemlich viel, was zu "den Wichtigsten" zählt, das macht es schwierig, wenn man konkret wird.

Die Alternative wäre, die Grafik ganz radikal zu vereinfachen, und nur noch dazu zu nutzen, erst mal Begrifflichkeiten zu klären....

Vielleicht als eine Art "Schalenmodell" (also eine Kugel mit mehreren Schichten drumrum)????- Im Kern fhem.pl, darum die "Configuration", die dann "Modules" enthält, die eben mehr oder weniger nah am Kern sind, oben "drumrum" eine Wolke, untendrunter "Sensors&Actuators", dabei aber gar keine spezifische Verbindungen zwischen einzelnen Elmenten, sondern nur noch "pauschale Pfeile"?

(Müßte man evtl. mal austesten, vielleicht hat auch jemand noch eine andere Idee)?

Würde dann dazu führen, dass man manches an Detailgrafiken erläutern müßte, aber z.B. auch den Homematic-Kram schlicht in den Homematik-Artikel "verbannen" könnte... (Mit Verlaub, aber CUL_HM gehört mMn. mittelfristig vermutlich in die Kiste "nicht mehr so wichtig").
Aber den "WLAN-Kram" ( ::) seht mir die Begrifflichkeit bitte nach...) nach vorne zu schieben, ohne das "Warnschild: Infrastruktur muß passen" aufzustellen ist auch suboptimal...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files