[Projekt-Blog] HomeCenter lite als Secondary Controller (updates abgeschlossen)

Begonnen von Beta-User, 23 Oktober 2020, 15:55:44

Vorheriges Thema - Nächstes Thema

Beta-User

Hallo zusammen,

jüngst ist mir u.a. auch ein Fibaro HomeCenter lite (mit etwas speziellen Features, siehe forum.fibaro.com/topic/42908-hcl-custom-recovery/) in die Hände gefallen. Motiviert hat mich v.a. die Idee, mal zu schauen, ob es für meine diversen Fibaro-Teile ggf. firmware-updates gibt und was man über diesen Weg ggf. an Infos darüber in Erfahrung bringen kann, was überhaupt die "Verbesserung" in der jeweiligen firmware ist.

FHEM (bzw. mein Z-Wave.Me USB Stick ZME_UZB1 mit "relativ aktueller" firmware) soll dabei weiter Primary Controller bleiben, denn eigentlich funktioniert ja alles...
Fernziel wäre ggf. eine Art "community-box" zu haben, die man dann als FHEM-User zeitweise erhalten kann, um "lohnende updates" zu machen.

Da mein erster  "Handbuch lese ich später"-Versuch erst mal gescheitert ist, einfach das HCL als Secondary Controller einzubinden, fange ich hier einfach mal eine Art Blog an, denn die Trefferliste zum Thema "Home Center" und "Controller" bringt grade mal 3-4 Treffer, die sich aber alle mit der "anderen Richtung" befassen, also FHEM als Secondary einzubinden:
[patch] Controller als Sekundärcontroller anlernen
FHEM in Verbindung mit Home Center Lite
Z-wave zme_uzb1 Einrichtung als Sekundärcontroller
Das Wiki ist zum Thema mehrere Controller auch nicht unbedingt sehr beredet, und der genannte 4. Treffer ist der, in dem mich krikan aufgeklärt hat, dass ein HC nötig ist, wenn firmware-updates machen will.

Ergo scheint diese Richtung was neues zu sein.

In diesem Beitrag im Fibaro-Forum ist zu erfahren, dass es die Funktionalität an sich gibt (eigentlich dachte ich, dass ich das versucht hätte, also FHEM-Dongle ganz normal in den Inclusions-Modus und dann den fraglichen Button im HCL drücken, aber autocreate ist stumm geblieben...). Also ist es entweder ein Funkproblem, ich habe doch die falsche Taste oder Reihenfolge erwischt oder FHEM kann es (noch) nicht.
Dass die andere Controller-Software eine Rolle spielen könnte, wird u.A. hier im symcon-Forum erwähnt.

Da dort auch der Hinweis zu finden ist, dass es ggf. über z-way gehen könnte, werde ich das mal austesten, denn einen 2. zwave.me-Dongle mit etwas älterer firmware habe ich eh' noch rumliegen und wollte dazu dann auch ein firmware-update machen (und dto. an meinem Haupt-dongle, dazu wollte ich sowieso mal ein ZWave-backup erstellen und testen). Der freie Dongle sollte dann auch in der Lage sein, als Sniffer zu dienen, denn hier heißt es:
In Expert UI there is a new Promiscuous mode of Zniffer to monitor packets between device (make sure to upgrade RaZberry/UZB firmware to version 5.39)

Na ja, mal sehen, was es ggf. zu berichten gibt.

Scheint jedenfalls ein länger laufendes Projekt zu werden, und falls jemand irgendwelche Daten haben will: Melden, aber möglichst mit genauer Anleitung, was und wie...
(Fyi: Ich habe auch noch zwei 868er-CC1101 an einem MapleCUN frei.)

Bis dahin erst mal,

Beta-User

Nachtrag:
In RaZberry2 als secondary Controller gab's mal den abgebrochenen Versuch, was ähnliches mit einem RaZberry zu machen.
Da findet sich zumindest der Hinweis, dass man das USB-FHEM-Dongle erst mal zum SUC erklären sollte:
set <Dongle1> sucNodeId 1 1 0
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

rudolfkoenig

ZitatAlso ist es entweder ein Funkproblem, ich habe doch die falsche Taste oder Reihenfolge erwischt oder FHEM kann es (noch) nicht.
Ob es an FHEM liegt oder nicht, kann man eingrenzen, indem man vor dem Knopf druecken "attr ZWDongle verbose 5" aktiviert.

Zitat(Fyi: Ich habe auch noch zwei 868er-CC1101 an einem MapleCUN frei.)
Ich habe vor 3.5 Jahren folgende MapleCUN Konfiguration erstellt (oder bekommen?), um ZWave Nachrichten zu verfolgen:

attr global logfile -
attr global modpath .
attr global statefile ./log/fhem.state.zwcul.scc

define telnet telnet 7072

define zBase ZWCUL /dev/cu.usbmodemd0482191@38400 00000000 01
#define zBase ZWCUL localhost:12345 00000000 01
attr zBase.6 dataRate 9600
attr zBase verbose 5

define SCC3 STACKABLE zBase
define z100k ZWCUL FHEM:DEVIO:SCC3:9600 00000000 01
attr z100k verbose 5
attr z100k dataRate 100k

define SCC1 STACKABLE z100k
define z9.6 ZWCUL FHEM:DEVIO:SCC1:9600 00000000 01
attr z9.6 verbose 5
attr z9.6 dataRate 9600

define SCC2 STACKABLE z9.6
define z40k ZWCUL FHEM:DEVIO:SCC2:9600 00000000 01
attr z40k verbose 5
attr z40k dataRate 40k

Zitat Doku:
ZitatIf the homeId is set to 00000000, then culfw will enter monitor mode, i.e. no
  acks for received messages will be sent, and no homeId filtering will be done.

Beta-User

OK, dann werde ich mal versuchen, das log vollzuknallen...

Zur Vorgehensweise: Erst mal nur mit verbose 5 am ZWDongle anfangen oder gleich "aus allen Rohren schießen"?

Fyi: Das ist seit langem (...) meine (auszugsweise) Konfig mit dem Maple - sollte daher kein Hexenwerk sein, das vollends anzupassen:
define MapleStack2 STACKABLE mapleCUN2define z100k ZWCUL FHEM:DEVIO:MapleStack2:9600 64757433 01
attr z100k dataRate 100k
attr z100k intruderMode 1
attr z100k verbose 4
define MapleStack3 STACKABLE z100k
define z40k ZWCUL FHEM:DEVIO:MapleStack3:9600 00000000 01
attr z40k dataRate 9600
attr z40k verbose 4

Da ich aber (eigentlich) nur 2 CC1101 frei habe: welche Datenraten-Kombi würdest du bevorzugen?
(Der Maple steht einen Stock tiefer (=da wo alle Nodes sind, nicht aber der FHEM-Server) wie der für die weiteren Tests geplante Standort des HCL).
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

rudolfkoenig

ZitatDa ich aber (eigentlich) nur 2 CC1101 frei habe: welche Datenraten-Kombi würdest du bevorzugen?
Soweit ich weiss, kommen NIFs (die erste Nachricht beim Anlernen) immer mit 9.6, ansonsten versuchen die Geraete 100k (wenn alle es unterstuetzen, und es funktioniert), mit Fallback auf 40k. Ich wuerde mit 9.6 und 100k anfangen.

Wenn meine Erinnerung nicht taeuscht, hat das Experiment mit dem MapleCun bei mir nicht funktioniert, und ich habe es nicht zu Ende untersucht. Ich blieb bei meinem CUL und eine Datenrate, bei mir wird ueberwiegend 40k verwendet.
Wenn man ausschliesslich ZWCUL verwendet, ist das auch einfacher: man Sendet 40k, und die Geraete antworten automatisch auf 40k :). Bis auf NIF, das kommt immer mit 9.6 :(

tux75at

Interessantes Thema ....

Ich habe auch einen Fibaro Home Center Light in der Schublade, sowie einen zweiten UZB Controller.
Wenn dies klappen könnte um Updates durchzuführen, wäre das sehr praktisch. Ich habe einmal upgedated und das war ein Tag arbeit :(

Beta-User

#5
So, kleines update:

Das HCL mal in die Nähe des USB-Dongles verbracht, an dem Dongle sucNodeId 1 eingestellt und addNode auf "on", und was findet sich ein, nachdem ich im HCL "Sekundärkontroller hinzufügen"=> starte Lernmodus geklickt hatte?!?

Das hier :) :
defmod ZWave_STATIC_CONTROLLER_21 ZWave 12345678 21
attr ZWave_STATIC_CONTROLLER_21 IODev zwaveme
attr ZWave_STATIC_CONTROLLER_21 classes SECURITY MULTI_CMD CRC_16_ENCAP MANUFACTURER_SPECIFIC VERSION TIME_PARAMETERS
attr ZWave_STATIC_CONTROLLER_21 room ZWave
attr ZWave_STATIC_CONTROLLER_21 vclasses CRC_16_ENCAP:1 MANUFACTURER_SPECIFIC:1 MULTI_CMD:1 SECURITY:1 TIME_PARAMETERS:1 VERSION:1

setstate ZWave_STATIC_CONTROLLER_21 2020-10-26 20:11:04 model FIBARO System HC2
setstate ZWave_STATIC_CONTROLLER_21 2020-10-26 20:11:04 modelConfig unknown
setstate ZWave_STATIC_CONTROLLER_21 2020-10-26 20:11:04 modelId 010f-0001-1000
setstate ZWave_STATIC_CONTROLLER_21 2020-10-26 20:10:58 timeToAck 0.031
setstate ZWave_STATIC_CONTROLLER_21 2020-10-26 20:10:58 transmit OK


Weiter sehe ich direkt auch im HCL eine zum aktuellen ZWave-Netz passende Zahl an neuen Geräten; auch erst mal sehr gut. Allerdings sind das irgendwie erst mal "tote Nummern", auf der Module-Detail-Seite kann ich zwar versuchen, "Aktuelle Konfiguration"/"Konfiguration lesen" oder "Gerätevorlage"/"Herunterladen" auszuführen, aber das erste ergibt schlicht irgendwas mit "background" und das andere meint, es wäre nichts "available"...

Am FHEM-Gerät war auch - jedenfalls auf den ersten Blick - nichts passendes zu finden, um da z.B. irgendwelche erweiterten Rechte zu übertragen oä..

Assoziation löschen und meine Geräte (teilweise) neu konfigurieren wollte ich eigentlich vermeiden....

Bei Home Center Konfiguration gab's dann einen Reiter Diagnosen mit einem Sub-Bereich Z-Wave (siehe screenshot). Da kann man dann eine "leichte Neukonfiguration" machen, was scheinbar dann dazu führt, dass die Parameter ausgelesen werden und man dann auch sieht, um was für Geräte es sich überhaupt handelt, vorher ist das sehr neblig...

Danach kann man checken, ob es neue Updates gibt, was beim Spirit und dem AEOTEC 3-Phasen-Messgerät ("fälschlicherweise" - jedenfalls, wenn man andere Quellen heranzieht) mit einem "not available" quittiert wird.
Jetzt habe ich eben mal ein update von v5.0 auf 5.1 - vermutlich an dem FGR-223 - angeschubst. Bin mal gespannt... (EDIT: hat geklappt).

Ach so: gesnifft habe ich erst mal nicht, jetzt hat's ja mit dem Includieren reibungslos funktioniert, und alles andere war/ist zwar nicht intuitiv, aber was soll's...
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,

mein "Projektchen" ist erst mal soweit abgeschlossen. Was an updates via HCL zu beziehen war, ist über diesen Weg auf den betreffenden Geräten drauf :) .

Auch der AEOTEC 6-fach-Sensor ist zwischenzeitlich auf dem aktuellsten Stand, das ging relativ fix und problemlos, nachdem ich einen Rechner mit Win+.net-Umgebung zur Verfügung hatte.

Was jetzt noch "fehlt" wäre ein Check, was ggf. über z-way zu machen wäre. Lt. zwave.me kann man z-way auch als secondary controller einbinden, aber dafür müßte ich erst mal wieder einen Pi rauskramen. Interessant erscheint mir dabei vor allem die Möglichkeit, über z-way recht umfangreiche Analysen des Z-Wave-Mesh durchzuführen, es gibt dazu ein "webinar" von Serguei Poltorak, das m.E. auch ohne laufendes z-way ganz gut manches zum Thema "optimiertes Mesh" erläutert.

Meine Erfahrungen und Erkenntnisse  sind zwischenzeitlich auch zusammengefasst im Wiki zu finden: https://wiki.fhem.de/wiki/Z-Wave_Firmware_Update. Falls da jemand was beitragen kann oder will: feel free - gegebenenfalls kann gerne auch ein Thread dazu im Wiki-Bereich aufgemacht werden. Leider habe ich nicht jede Kleinigkeit mitgeschnitten, z.B. wäre noch interessant gewesen, was das update von FGR-223 eigentlich an "Verbesserungen" bringen sollte.

Ist so ein Fibaro-update mal durch, erhält man keine weiteren Infos mehr, und auch die eigentliche firmware scheint jedesmal neu auf einem zentralen Server abgerufen zu werden. Jedenfalls konnte ich auch keine Dateien im Dateisystem finden, die mit den updates in Verbindung zu bringen wären.

Fazit:
Na ja, will nicht behaupten, dass die ganze Aktion insgesamt besonders "ertragreich" gewesen wäre, es waren überhaupt "nur" updates für 50% der Modelle verfügbar, und ob die wesentliche Verbesserungen bringen? K.A.....
Mein Hauptziel habe ich aber erreicht: Ich weiß jetzt wenigstens, woran ich bin - es hat mich ziemlich genervt, dass (abgesehen von der löblichen Ausnahme mit den AEOTEC-Modellen!) nirgends so richtig zu erfahren war, ob mein "Fuhrpark" denn jetzt halbwegs auf dem aktuellen Stand ist, und welche updates ggf. was bringen.


Next steps:
Eigentlich sollte das HCL jetzt wieder exkludiert werden, aber da muß ich auch erst mal lernen, wie das überhaupt geht. Das mit ZWdongle auf Exklusionsmodus einstellen hat noch geklappt, aber wo die "Gegenstelle" im HCL zu finden ist, stand leider nicht im nicht vorhandenen Handbuch - falls da also jemand einen Tipp hat: feel free...
Das habe ich einfach auf "Netzwerk verlassen" gesetzt, danach waren alle meine ZWave-Geräte nicht mehr vorhanden, "eigentlich" sollte das also ok sein, wenn man davon absieht, dass es im Dongle noch gespeichert ist.



Zu guter Letzt hatte ich ja angekündigt, das Teil ggf. auch der Allgemeinheit zur Verfügung zu stellen - wie dargestellt, ist das aber (Kenntnisstand: heute) ausschließlich für Fibaro-Geräte tauglich.

Besteht denn daran überhaupt Interesse?
Dann würde ich die "Bedingungen" ggf. etwas konkretisieren, dachte an sowas wie:
Wer nicht anders aktiv zu FHEM beiträgt, macht pro angefangener 10 Tage eine Spende von mind. 10 Euro an den Verein.
Jeder "Entleiher" übernimmt die Versandkosten von und zu mir - ich will nicht viel mehr machen müssen als das Ding wieder neu zu verpacken und das (mir übersandte) Label draufpappen. Findet sich jemand zur Anschlußüberlassung, entfällt die Rücksendung, ich will dann nur jeweils wissen, wo das Ding ist.
Versandrisiko trägt immer der Entleiher, bis es bei der nächsten Station angekommen ist - will sagen: Ggf. muß der, der das Ding verschlampt oder einem unzuverlässigen Transport-Dienstleister überläßt, halt dafür sorgen, dass wieder eines zur Verfügung steht.
Die Erwartung an alle Entleiher wäre dann noch, Infos zu neuen firmwares, aufgetretenen Problemen und deren Lösung irgendwie wieder in die Community zurückfließen zu lassen.

Falls es mir zu viel wird (und sich niemand anders findet, der den Umlauf organisieren mag) oder sonst Probleme auftauchen, ist die Aktion halt beendet.

Fragen & Anmerkungen: Gerne.
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

rob

Auf jeden Fall klasse, dass Du Dir die Mühe gemacht hast. Ist schon irgendwie ernüchternd bzgl. "Was bringen Updates faktisch".

Gerade bei den Qubinos hätte ich mir seitens Hersteller mehr gewünscht. Sie sollen ja Z-Wave+ beherrschen, Secure-Include ist mir bislang nicht gelungen und aufgrund dieser Infos (https://forum.fhem.de/index.php/topic,101617.msg957066.html#msg957066) wohl eh aussichtslos.

Aber auch den Fibaro FGS-223 konnte ich nicht secure includieren, irgendwas hat er nicht gefunden. Habs aufgegeben.

Wenigstens bei den Fibaros hätte ich doch erwartet, dass per Upgrade einiges besser werden kann. Naja, so weiß ich, dass es der Mühe nicht lohnt.
OT: im direkten Vergleich macht der Zigbee-Krams auch kaum eine bessere Figur. Alles Funkgedöns eben ;)

Viele Grüße
rob

Beta-User

Danke für die Rückmeldung (und @krikan für die Ergänzung im Wiki bzgl. der POPP-Geräte).

"Ernüchternd" finde ich jetzt für meine Belange nicht die treffende Wortwahl. An sich gab es in meiner Installation ja vorher keine wirklichen Probleme. Von daher finde ich das "Ausbleiben von firmware-updates" jedenfalls dann kein Drama, wenn man nicht (wie bei den IKEA-Dingern@ZigBee) den Eindruck haben kann, dass das Produkt beim Kunden reift. Und dass man vor diesem Hintergrund das Thema updates nicht zu hoch hängt, ist ja dann in der Sache auch nicht verkehrt, wobei ich mir schon etwas mehr Offenheit in der Informationspolitik wünschen würde.

Zu "secure" habe ich zwischenzeitlich auch eher die Neigung, das wegzulassen, wo es nicht zwingend ist, von daher "kratzt" mich das weniger.

Was den Vergleich mit ZigBee angeht, neige ich dazu, ZWave für deutlich transparenter zu halten. Habe am WE mit zwei neuen Devices rumgespielt: einen ZWave-Bewegungsmelder von Steinel (weitere Info dazu folgt bei Gelegenheit) und einen chinesischen ZigBee Aktor (ähnlich zu QS Zigbee S04 2C LN  2 ways, aber without neutral) . Der Steinel ist zwar irgendwie ein komplexes Device, aber wenn man da mal den Beipackzettel durchgelesen hat und sich die diversen Channel-Devices angesehen, die FHEM daraus bastelt, kann man wohl sehr akkurat einstellen, wie sich das Ding gegenüber anderen ZWave-Geräten verhalten soll, z.B. Einschalten, aber nur, wenn ein bestimmter Helligkeitswert unterschritten ist. Sowas geht in ZigBee@deconz wohl nur über die Zentrale, die dann aber eben bei jedem Schaltvorgang verfügbar sein muß.
Der ZigBee-Aktor dagegen wird grade mal mit "permit join" akzeptiert, aber dann war es das für's erste - es gibt keine schaltbaren Kanäle, nada. Man sieht grade mal in deCONZ-GUI (auf dem Laptop), dass eine Verbindungbesteht und dass (lokale) Schaltvorgänge irgenwie an das Dongle versendet werden. (Angeblich ist da zigbee2mqtt schon weiter und kann mit den Dingern bzw. deconz mit den "with neutral"-Geschwistern.)
Da scheint die wechselseitige Identifizierung der Geräte bei ZWave deutlich besser zu sein.

Na ja, das "perfekte System" scheint es eben nicht zu geben...
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

Yil

Super spannend, danke! Bleibt die Frage: mit welchem Befehl bindet man das Fibaro HomeCenter 3 Lite in fhem ein? Ich möchte das ebenfalls als secondary controller betreiben und vor allem die zahlreichen wall plugs aktualisieren, die ich betreibe und die immer wieder Probleme machen.
HM CCU2 mit ca. 35 HM-Komponenten inkl. Bausätzen
fhem auf RPi mit Sonos, EnOcean-CUL, ZWAVE-CUL und Bluetooth
Osram Lightify

Beta-User

Puh, ist schon eine Weile her, seitdem liegt das Ding im Keller...

Aber das hier sollte es eingentlich schon gewesen sein:
Zitat von: Beta-User am 26 Oktober 2020, 21:54:54
Das HCL mal in die Nähe des USB-Dongles verbracht, an dem Dongle sucNodeId 1 eingestellt und addNode auf "on", und was findet sich ein, nachdem ich im HCL "Sekundärkontroller hinzufügen"=> starte Lernmodus geklickt hatte?!?
Wobei mir "Sekundärkontroller" grade "spanisch" vorkommt, eigentlich sollte FHEM weiter Hauptcontroller bleiben. Kann sein, dass einige der Probleme, die ich effektiv hatte grade erst dadurch entstanden sind, dass FHEM nicht Primärkontroller geblieben zu sein scheint...
Jedenfalls war das ganze an sich halbwegs selbserklärend, wenn man mal die Begrifflichkeiten kennt und weiß, nach was man eigentlich suchen muss.
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

Yil

HM CCU2 mit ca. 35 HM-Komponenten inkl. Bausätzen
fhem auf RPi mit Sonos, EnOcean-CUL, ZWAVE-CUL und Bluetooth
Osram Lightify