Grüße aus Frankfurt

Begonnen von creativeHQ, 17 Dezember 2019, 22:51:17

Vorheriges Thema - Nächstes Thema

creativeHQ

Hallo Zusammen,

ich dachte es ist höflich, mich (kurz) vorzustellen, bevor ich anfange dumme Fragen zu stellen  :P

Nein, ich bin naturlich fleißiger Wiki/Commandref/etc Leser, aber es ist leider vieles nicht immer so ausführlich dokumentiert und da mein System vor allem auf  Tasmota/Arduino Geräten basiert und nicht so sehr auf HM/IT, bewege ich mich nicht so sehr auf "bestellter Erde", sondern muss wohl mehr Vorarbeit leisten.

Zu FHEM bin ich gekommen weil der deutlich jüngere, gute Freund eines Bekannten, dem ich hohe Kompetenz unterstelle es mir empfohlen hat, ursprünglich hatte ich den Einsatz von OpenHAB geplant. Aber ich habe es mir angeschaut und sehe ein paar Gründe, warum FHEM für mich die richtige Wahl ist.

1) Es hat vielleicht nicht die meisten Installationen, aber vielleicht die meisten umfangreichen, echten, langjährigen Produktivsysteme im Einsatz. Ich brauche kein System, das sich irgendwelche Hipster auf eine Raspi packen, um damit 2 HUEs zu steuern und das Hausmautomatisierung zu nennen.
2) Es wird getragen von einem Verein. Klingt zwar altmodisch, aber "Meister" und "Geselle" klingt auch so, das klappt aber. Es gibt hier ein paar sehr erprobte Strukturen, die vielleicht nicht immer fancy klingen, aber funktionieren.
3) Irgendwie lief FHEM von Anfang an besser, ich kam mit dem Aufbau des Systems viel schneller voran als bei openHAB. Ich spreche hier aber noch von der Home-Automatisierbarkeit, noch nicht von der Automatisierung.
4) FHEM ist echt schlank. BrokerIO hat pro MQTT device, also jeweils (!) einen Prozess aufgemacht der 20 MB Speicher Speicher reserviert hat...

Die ersten Schwierigkeiten habe ich auch schon erfahren. Die teilweise bizarren Syntaxunterschiede zwischen den Modulen, vor allem bei Trennzeichen. Leider nicht immer gut dokumentierte Module und set-up Fehler die durch "blocking" Funktionen das System einfieren lassen. Aber wem erzähl ich das...

Das GUI ist mir zweirangig, wenn die Automatisierung so läuft wie ich möchte ist es eigentlich nur noch ein debug interface. Mal schauen ob ich soweit komme.

Aber man lernt ja. Momentan steuere (genauer, regele) ich noch nichts kritisches.

Ich wohne in einem Haus(-halt) mit 4 Personen und dem "Hauselfen" Alexa. Ich arbeite IT-nah, bin aber mehr auf der Projekt-seite.

Ich habe zwei Raspi 3b, einen schwarzen als Backend (Node-Red, Influxdb, Mosquitto und der reverse-proxy nach draußen) und einen weißen, für Grafana und Fhem. Ich nenne sie Yin und Yang. Die Last und der Speicherbedarf verteilen sich so ganz gut, auch wenn Yin durch influxdb etwas mehr zu tun hat.

Dazu gesellen sich derzeit 39 (physische) Tasmota-Geräte, das ist aber noch im Aufbau, ein paar alte 433 MHz Rolladenschalter, dazu Heizung/ Klima von Daikin, ein kleiner Stall an Echo's, eine Yamaha Stereoanlage, eine Fritzbox, einen raspbee und ähnlicher Kleinkram. Da viele der Tasmotas sowohl Sensoren als auch Aktoren sind, überlege ich diese noch nach Aufgabe als seperate MQTT devices weiter zu trennen. Ich hatte auch überlegt über Dummy devices eine Art Abstraktionsschicht einzuführen. Davon bin ich allerdings abgekommen, da mein Setup auf der logischen Seite ja ziemlich homogen ist. So extrahiert ein einzelnes expandJSON den Stream aller 39 Tamotas durch filterung des devicenames.

Ich habe schon das residents modul eingerichtet incl. geofancy via reverse proxy und prosody als XMPP/Jabber, also messaging server; derzeit läuft er local, bzw im VPN, das ich remote vom Handy nutze.

Erste Automatisierungen der Rolläden und einzelner Lichter habe ich über Notifies und Ats erledigt, merke aber, dass das zwar logisch sehr sauber aufgesetzt werden kann, es aber wahlweise sehr schnell unübersichtlich und/oder schwer zu warten werden kann, je nach dem an welche Paradigmen man sich hält.

Ich habe über Yaahm nachgedacht aber irgendwie keinen Einstieg gefunden. Momentan arbeite ich an der Integration von residents und meinen Bewegungsmeldern mit dem Homezone Modul. ich glaube, dass mir das schon viel dessen liefert, was ich haben möchte. Ein Haus, das darauf reagiert, wie es bewohnt wird. Vielleicht kann ich das als "taktische" Ebene aufbauen, und irgendwan Yaahm als Strategische Ebene einfügen, wenn ich es durchblickt habe.

Bei dem Zusammenwirken von FHEM und Tasmota scheine ich bis auf ganz grundlegende Funktionen noch Basis-Arbeit zu machen, oder viele behalten ihr Wissen für sich... Es hat wohl einen Grund warum auf der Tasmota Homepage FHEM nicht als unterstütztes Home-Automation-System erwähnt wird, schade eigentlich.

So habe ich als eine erste Fingerübung ein in einer Tasmota Dose implementiertes Thermostat (an der Dose hängt ein Temperatursensor), bei dem ich über FHEM nur die Ziel-Temperatur einstellen brauche und die Regelung selber im Gerät läuft. Außerdem merkt sich die Dose die Einstellungen bei Stromausfall und regelt damit im Zweifel auch ohne WLAN/FHEM weiter. Und Alexa kann es über FHEM auch ansteuern. Da gibt es also Potential.

Grüße,

Niko

Wzut

Frankfurt .. welches ? Ich hoffe mal das richtige /Main und nicht das dazu gekaufte /Oder ?
dann mal Gruß zurück aus 30km Entfernung :)
Zitat von: creativeHQ am 17 Dezember 2019, 22:51:17
und nicht so sehr auf HM/IT, bewege ich mich nicht so sehr auf "bestellter Erde", sondern muss wohl mehr Vorarbeit leisten.
als ich vor fünf Jahren mit FHEM angefangen habe, war das Forum und die Einsteiger Doku noch verdammt FS20 lastig. Und ja ich wollte eigentlich in den ersten vier Wochen aufgeben da die meisten Beispiele auf meine damalige Firmata Umgebung einfach nicht umzusetzen waren :( Durchgehalten habe ich eigentlich nur weil ich damals eine Alternativ Software für meine MAX! Geräte gesucht habe. Nunja aber irgendwann platzt der Knoten im Hirn und dann ist es völlig wurscht für welches System ein Beispiel ist, man übersetzt es geistig einfach auf sein eigenes System :) Beigeistert hat mich recht schnell allerdings das jedes Modul offen ist und so habe ich recht früh angefangen Dinge dir mir nicht passten in den Modulen einfach passend zu machen. Ein Weg den ich inzwischen auch wieder verworfen habe, da es damals meist reine Unkentniss war wie man es richtig macht oder das mit fast mit jedem Autor reden kann und Verbesserungsvorschläge i.d.R. gut angenommen werden. Umsonst war die damalige Arbeit allerdings nicht, man lernt auf dem Weg halt verdammt viel über Module.

Deine Tasmota Kritik kann ich nicht so ganz nachvollziehen, ok ich selbst habe nur vier Gosunds mit Tasmota am Start und auch nur für so unwichtige Dinge wie jetzt den ganzen Weihnachts-Beleuchtungs-Kram, alledings nutze ich sie über den FHEM eignen MQTT Server und kann bis jetzt nicht klagen. Vllt soltest du dich auch mehr um MQTT kümmern und ggf. im passenden Unterforum dir weiter Unterstützung holen.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Beta-User

Moin,

auch von mir ein herzliches Willkommen hier im Forum!

Dass hier extrem viel HM-(BidCoS)-Erfahrung zusammenkommt und das auch in der Einsteigerdoku "überrepräsentiert" ist, hat mich auch dazu verleitet, das einzusetzen. Zwischenzeitlich kenne ich ein paar andere Lösungen und kann behaupten, dass man überall auf irgendwas stößt, das nicht so ist wie erwartet... (Heute würde ich jedenfalls vermutlich keine eQ-3-Hardware mehr einsetzen).
Von daher: einfach fragen, es ist ziemlich wahrscheinlich, dass es doch (auch be "exotischen" Dingen) jemanden gibt, der "sowas" schon mal in der Hand hatte oder sonst eine Idee dazu hat.

Was das Thema Tasmota (eigentlich: JSON zusammenbauen mit MQTT_DEVICE?) angeht, kann ich nur einen Blick auf die MQTT2-Modulfamilie empfehlen. Da geht das sendeseitig mMn. viel einfacher (ich hatte mal den ziemlich untauglichen Versuch unternommen, ein extra Modul für den MiLight-Hub von Chris Mullins zu schreiben, der auch JSON empfangen will). Für's parallele Antesten/Umstellen von MQTT2_DEVICE zu MQTT_DEVICE gibt's einen Thread im MQTT-Bereich des Forums, bei Interesse kann ich den Link raussuchen.

Ansonsten: Viel Freude beim weiteren Einarbeiten!

Gruß, 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

creativeHQ

Hi,

Vielen Dank für euer freundliches Wilkommen.

Zitat von: Wzut am 18 Dezember 2019, 07:59:13
Frankfurt .. welches ? Ich hoffe mal das richtige /Main und nicht das dazu gekaufte /Oder ?

Ja, aus FFM...

Naja, ich will nicht gleich erst mal mosern in meinen ersten Posts, dann würde ich wohl zurecht gesagt bekommen, schreib doch ein eigenes Modul dafür...

Aber was Beta-User sagt bringt es eigentlich auf den Punkt:

Zitat von: Beta-User am 18 Dezember 2019, 09:36:42
Was das Thema Tasmota (eigentlich: JSON zusammenbauen mit MQTT_DEVICE?) angeht

Als ich FHEM installiert hatte, hatte ich noch gehofft, dass die Abstraktion höher ist als Transportprotokoll und Datenformat.

Dazu kam dass ich dummerweise das erste Beispiel aus dem Wiki genommen habe, weil es darunter mit ESPeasy weiterging, und erst viel später gesehen habe, dass darunter noch viele weitere Beispiele folgten... Und beim ersten Beispiel fehlen so grundlegende Dinge wie der Eventmap von ON/OFF auf on/off oder dass der "state" ein Update über MQTT bekommt, wenn man z.B. das Gerät über den Schalter/Knopf angeschaltet hat. Da funktionierten also recht grundlegende Dinge nicht und ich musste es mir zusammensuchen. Ich dachte, so schwer kann das nicht sein. War es auch nicht, aber halt doch irgendwie ein unglücklicher Start.

Jetzt genieße ich halt die Freiheit, die Devices als generische MQTT devices aufzusetzen, und dann mit wachsender Erkenntnis "aufzurüsten" ;) Das ist vielleicht gar nicht schlecht. Aufwändiger als wenn alles vorgekaut ist, aber da sie bei mir das Rückgrat der Infrastruktur bilden (als Steckdosen, Schalter, Rolladen/Torsteuerungen und diversen Sensorknoten, später noch als IR-Sender und vielleicht auch als Statusdisplays) ist es nicht verkehrt, dass ich das zu Fuß machen muss.

Ich muss mir noch mal genau die Unterschiede zwischen dem MQTT Modul und MQTT2 anschauen. Vielleicht löst das noch den einen oder anderen Fallstrick.

Nochmals Dank und Grüße,

Niko




Beta-User

Zitat von: creativeHQ am 18 Dezember 2019, 15:07:32
Jetzt genieße ich halt die Freiheit, die Devices als generische MQTT devices aufzusetzen, und dann mit wachsender Erkenntnis "aufzurüsten" ;) Das ist vielleicht gar nicht schlecht. Aufwändiger als wenn alles vorgekaut ist, aber da sie bei mir das Rückgrat der Infrastruktur bilden (als Steckdosen, Schalter, Rolladen/Torsteuerungen und diversen Sensorknoten, später noch als IR-Sender und vielleicht auch als Statusdisplays) ist es nicht verkehrt, dass ich das zu Fuß machen muss.
Auch MQTT2_DEVICE macht nicht unbedingt alles "automatisch", erleichtert es aber sehr, die Dinge passend zu konfigurieren.
Was mich (als ziemlichen Tasmota-noob...!) bei der Arbeit an den attrTemplates (zur Konfiguration der MQTT2_DEVICEs) immer wieder gewundert hat, war das geringe Wissen, das bei den (echten) Nutzern teils vorhanden war. Angefangen damit, dass alle diese "dusselige" eventMap abgeschrieben haben statt "das Übel an der Wurzel" zu packen und schlicht den ON/OFF-String in on/off usw. umzukonfigurieren. Ich würde wetten, dass das in 95% der Fälle kein Problem gewesen wäre, weil die Dosen eh' nur via FHEM gesteuert werden...

Wie dem auch sein: Bin mal gespannt auf dein Feedback zu Tasmota@MQTT2_DEVICE ;D .
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

amenomade

Zitat von: Wzut am 18 Dezember 2019, 07:59:13

dann mal Gruß zurück aus 30km Entfernung :)

22 km! Gewonnen! ;) Willkommen Niko
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

creativeHQ

Zitat von: Beta-User am 18 Dezember 2019, 15:17:48
Ich würde wetten, dass das in 95% der Fälle kein Problem gewesen wäre, weil die Dosen eh' nur via FHEM gesteuert werden...

Wie dem auch sein: Bin mal gespannt auf dein Feedback zu Tasmota@MQTT2_DEVICE ;D .

Ansonsten werden die meisten Tasmotas vermutlich am ehesten noch durch andere Tasmotas gesteuert, und denen ist Groß- und Kleinschreibung ja egal, der Grund warum das mit dem Eventmap ja so einfach funktioniert. So wirklich elegant fand ich die Lösung damit aber auch nicht.

Ich habe mir gestern den Spaß gegönnt mal alle über cmnd/Gruppentopic/Mqtthost auf einen MQTT2SServer umzuleiten. Autocreate complex war an und das war ein ziemlicher Gaudi bei 40 Geräten. Der Raspi hat ganz schön gerödelt und am Ende hatte ich einen Berg "DEVS-XXXXXX" devices.  Bisher war mir der mqtt uclient name ja herzlich egal. Das werde ich jetzt ändern, außerdem werde ich die Punkte die ich derzeit in meinen Devicenamen verwende durch Unterstriche ersetzen. Das erspart mir auf Dauer eine Menge and Escape-\. Noch ist das zu machen, ich habe erst ein knappes Dutzend At's und Notifies eingerichtet...

Auf den ersten Blick sieht es wirklich gut aus. Vorteil ist ganz klar, dass man mit den Templates die Geräte einheitlich einrichtet, und man weniger geneigt ist an einem device "rumzubasteln" und dann hinterher überlegen zu müssen, was man jetzt genau an allen anderen ändern muss.

Ich bleibe aber bei meinem Set-up, dass ich für jeden Knopf auf den Lichtschaltern eigenes Device anlege. Also Power1, Power2, etc. jeweils getrennte Geräte sind. Die muss ich dann halt die automatisch angelegten Devices kopieren.

Also: ja, schick! Mit den MQTT2 devices fühlt es sich ja schon sehr viel mehr so an wie ich es mir erhofft hatte. Und dadurch, dass die meisten Einstellungen ja über die Templates gemacht werden können bzw. man ja auch im Device noch die volle Kontrolle hat und nicht alles irgendwo "tief unter der Haube" im Modul definiert ist, vereint es wohl das beste aus beiden Welten.

Grüße,

Niko

Beta-User

 :)

Was eigene Devices pro Kanal angeht: Macht Sinn und es gibt in der Regel bei mehrkanaligen die Wahl zwischen "unified" und "split"!
Die split-Templates bauen automatisiert eigene/weitere Devices.

ABER: die Tasmota-attrTemplate sind noch auf dem "alten Stand" und nutzen jsonMap nur selten. Ich will das bei Gelegenheit umbauen, und wenn das jemand machen würde, der das auch (intensiv) nutzt, wäre das klasse und vermutlich noch weiter an dem dran, was du eigentlich haben willst. Orientieren könntest du dich an dem "tasmota_plug_with_rgbw_split", damit habe ich jüngst rumexperimentiert und finde das gut so (da landet dann "POWER2" auch in state vom 2. Gerät, ohne dass man das noch irgendwie umpacken müßte).

Was mir noch fehlt, wäre je ein template, mit dem man von neuer in alte Welt und umgekehrt transferieren könnte (damit bisherige user diese breaking change irgendwie umgehen/rückgängig machen können...). Ist aber schwieriger als ich dachte, und bisher hatte ich einfach keine Veranlassung, mich intensiver mit Tasmotas zu befassen (sonst hat es auch keiner gemacht, was jsonMap anging), daher ist das (jetzt würde ich sehr laut sagen: leider!) nicht früher erfolgt...
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