Der deCONZ-firmware-update-Thread

Begonnen von Beta-User, 28 Januar 2020, 11:27:07

Vorheriges Thema - Nächstes Thema

Beta-User

Vielleicht noch ein paar Klarstellungen:

Diese .ota.signed-files sind Container, die müssen erst ausgepackt werden, und das OTA-Tool kann das und weiß dann wohl auch, was wohin gehört.
Wer es automatisiert, sollte wohl auch dafür sorgen, dass alte files aus dem ~/otau gelöscht werden; bei mir liegt da aber z.B. auch noch die file von dem Jung drin, die sollte  eigentlich sicherheitshalber da bleiben...

Ob es überhaupt Sinn macht, derartige updates zu automatisieren, wäre eine weitere Frage. Denn nicht immer werden Verbesserungen, die sich ein Hersteller ausdenkt, von allen Usern auch als solche empfunden (ich bin Befürworter der 1.5-er firmware auf en HM-RT's, aber einige haben die 1.4 wieder aufgespielt...), und ggf. muss man ja auch wissen, ob/wann man ein (batteriebetriebenes) Device denn dann "anschucken" kann.

Dann: phoscon und deconz sind zwei Paar Stiefel, phoscon ist closed source und nutzt eben nur einen Teil der features, die die open source-Lösung deconz grundsätzlich anbietet. Das merkt man z.B. auch dann, wenn bestimmte Sensoren in phoscon nicht angezeigt werden, aber über die HUEBridge durchaus sichtbar sind und auch in FHEM verwendet werden können. Allerdings frage ich mich zunehmend, ob/wie man entweder HUEBridge aufpimpen könnte, um z.B. solche features wie das OTA-Tool aktivieren zu können (geht evtl. über json-Kommandos, die aber wenig dokumentiert sind), oder eben wie man auf deCONZ-GUI remote zugreifen kann. Das hat justme1968 mal als Option irgendwo erwähnt; vielleicht kennt sich ja jemand mit sowas aus, es ist wohl nur ein installierter xserver erforderlich, auf den man dann remote zugreifen kann. Ich habe nur leider zu wenig Plan von sowas...

Ansonsten: Danke für den Hinweis auf die zu aktivierende Option in den erweiterten Einstellungen der alten App.

Vielleicht mag sich jemand die Mühe machen, den "Stand der Dinge" mal Wiki-konform aufzubereiten? Das hier sollte eigentlich nur dazu dienen, die Infos mal zu sammeln, aber langsam wird es unübersichtlich... ;)
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

Udomatic

#46
Zitat von: Beta-User am 24 November 2020, 08:11:38
Vielleicht noch ein paar Klarstellungen:

Diese .ota.signed-files sind Container, die müssen erst ausgepackt werden, und das OTA-Tool kann das und weiß dann wohl auch, was wohin gehört.
Wer es automatisiert, sollte wohl auch dafür sorgen, dass alte files aus dem ~/otau gelöscht werden; bei mir liegt da aber z.B. auch noch die file von dem Jung drin, die sollte  eigentlich sicherheitshalber da bleiben...

Ob es überhaupt Sinn macht, derartige updates zu automatisieren, wäre eine weitere Frage. Denn nicht immer werden Verbesserungen, die sich ein Hersteller ausdenkt, von allen Usern auch als solche empfunden (ich bin Befürworter der 1.5-er firmware auf en HM-RT's, aber einige haben die 1.4 wieder aufgespielt...), und ggf. muss man ja auch wissen, ob/wann man ein (batteriebetriebenes) Device denn dann "anschucken" kann.

Genau aus diesem Grund lade ich mir lieber das Firmware Update herunter und spiele es selbst ein, wenn es Sinn macht z.B. bei Feature Upgrades oder Stabilisierungen, statt das automatisiert drüber bügeln zu lassen.

Grundsätzlich finde ich die Github Übersicht dazu schon ganz gut

https://github.com/dresden-elektronik/deconz-ota-plugin

Lässt sich das Plugin vlt. über FHEM ansteuern, sodass Update Files über FHEM eingespielt werden können?


Zitat von: Beta-User am 24 November 2020, 08:11:38
Dann: phoscon und deconz sind zwei Paar Stiefel, phoscon ist closed source und nutzt eben nur einen Teil der features, die die open source-Lösung deconz grundsätzlich anbietet. Das merkt man z.B. auch dann, wenn bestimmte Sensoren in phoscon nicht angezeigt werden, aber über die HUEBridge durchaus sichtbar sind und auch in FHEM verwendet werden können. Allerdings frage ich mich zunehmend, ob/wie man entweder HUEBridge aufpimpen könnte, um z.B. solche features wie das OTA-Tool aktivieren zu können (geht evtl. über json-Kommandos, die aber wenig dokumentiert sind), oder eben wie man auf deCONZ-GUI remote zugreifen kann. Das hat justme1968 mal als Option irgendwo erwähnt; vielleicht kennt sich ja jemand mit sowas aus, es ist wohl nur ein installierter xserver erforderlich, auf den man dann remote zugreifen kann. Ich habe nur leider zu wenig Plan von sowas...

Ansonsten: Danke für den Hinweis auf die zu aktivierende Option in den erweiterten Einstellungen der alten App.

Vielleicht mag sich jemand die Mühe machen, den "Stand der Dinge" mal Wiki-konform aufzubereiten? Das hier sollte eigentlich nur dazu dienen, die Infos mal zu sammeln, aber langsam wird es unübersichtlich... ;)

Aus Entwickler Sicht kann ich das wenig beurteilen aber aus meiner persönlichen Anwender Sicht ist Phoscon eine nette Weboberfläche, um Geräte schnell anlernen zu können. Wer kein FHEM hat kann dann ein paar Automatisierungen leicht darüber realisieren.

Die wirklich gute Übersicht und das Verständnis eines Zigbee MESH Netzes bekommt man meiner Meinung nach nur über die deConz Gui, die ich oft nutze, und eben auch deutlich mehr kann als das Phoscon Web Interface. Auch für das OTA Update. Dazu habe ich VNC auf dem PI aktiviert und greife per RealVNC App auf die Gui zu.

Seit kurzem gibt es eine wirklich gute Übersicht zur Klarstellung / Differenzierung von deConz / Phoscon / Gateway / APIs etc...

https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/deCONZ-for-Dummies

Gibt es schon eine Wiki Seite zum Thema oder muss diese neu erstellt werden?

2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Beta-User

#47

Zitat von: Udomatic am 24 November 2020, 10:57:37
Grundsätzlich finde ich die Github Übersicht dazu schon ganz gut

https://github.com/dresden-elektronik/deconz-ota-plugin
Sieht gut aus. Eigentlich erübrigt sich damit m.E. eine eigene Seite im FHEM-Wiki. Es gibt einen kurzen Abschnitt dazu im "allgemeinen ZigBee-Artikel" (https://wiki.fhem.de/wiki/ZigBee#Firmware_updates). Wenn man es kurz halten kann, könnte man das mit ein paar Links aufpimpen, so dass man von dort aus alles notwendige findet?

ZitatLässt sich das Plugin vlt. über FHEM ansteuern, sodass Update Files über FHEM eingespielt werden können?
Vermutlich nicht (so einfach), aber zum einen sollte man sowieso gezielt vorgehen (s.o.), und zum anderen ist der "Schalter" für das automatische OTA-Aktivieren sowieso nur ein Eintrag in irgendeiner Konfigurationsfile, den man eben von phoscon-alt wie auch deCONZ-GUI wie auch mit einem Texteditor aktivieren kann...

Zitataber aus meiner persönlichen Anwender Sicht ist Phoscon eine nette Weboberfläche, um Geräte schnell anlernen zu können. Wer kein FHEM hat kann dann ein paar Automatisierungen leicht darüber realisieren.
Finde das auch nett, aber es ist halt (zunehmend?) unvollständig. Von daher wird mein persönlicher Weg eher der sein, das "permit_join" über HUEBridge anzuschubsen, wenn es "einfach" ist, und für "spezielle Fälle" dann eben die "Vollversion" deCONZ-GUI herzunehmen. Darüber kann man dann auch gezielt updates starten, aber eben auch noch weitaus mehr über "schwierige Devices" rausfinden.

Mein Weg wird aber nicht vnc sein (da gruselt es mich irgendwie, klingt nach voller GUI-Version auf dem Server), X11-forwarding scheint mir da die bessere Wahl zu sein. Ein paar Quellen dazu (auch als Merker für mich):
https://wiki.ubuntuusers.de/SSH/#X-Forwarding (EDIT: die paar Zeilen in den beiden Dateien unter /etc/ssh sind (iVm. daemon-Neustart) ausreichend, um deCONZ-GUI auf einen anderen Linux-Rechner zu zaubern).
https://www.youtube.com/watch?v=auePeI8vZA8 (da ist auch erklärt, wie man unter Win das X11 angezeigt bekommt)
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2126#issuecomment-560491101 (summary für deCONZ-GUI)


Zitat
https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/deCONZ-for-Dummies
Könnte auch noch in den zentralen ZigBee-Artikel mit rein, allerdings weiter unten in den betreffenden Abschnitt. Für FHEM-Erstleser ist erst mal wichtig zu verstehen, dass es eben unterschiedliche Dinge sind (habe da auch etwas gebraucht, um das zu kapieren).
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

Spartacus

Moin,
ich noch mal! Hat irgendjemand etwas dazu gefunden, ob sich die IKEA Schalter updaten lassen? Das funktioniert bei mir definitiv nicht. Habe zwei von den 5fach Schaltern, einen mit FW 1.2.223 und einen mit FW 2.3.014. D.h. ich erwarte eigentlich, dass zumindest der 1.2er auf eine 2er Version kommt.

Danke,
Spartacus
Fhem-System: 1 x raspberry PI Typ B, 1 x enOcean PI Typ B | Enocean: PTM210, FMS61NP, FAM14, 2 x FSR14-4x, FTS14-EM | LaCrosse: 2 x TX29D über Jeelink V3 | 1-Wire: 2 x DS18B20 über DS9490R

carlos

Hallo,
Den update habe ich auch wochenlang probiert. Hat nie funktioniert.
Habe es dann mit zigbe2mqtt gemacht.
Das ging dann damit recht schnell.

Gruß

Carlos
FHEM svn auf Intel NUC mit proxmox,1 UDOO, 3 Raspberry Pi, signalduino, nanoCUL, div. Homematic Komponenten, toom Baumarkt Funksteckdosen, einige sonoffs, hue, shelly

Tungsten

#50
Moin Zusammen,

ich versuche auch seit ein paar Tagen per OTAU eine E27 IKEA Tradfri weiß zu aktualisieren.

Files sind im otau Folder vorhanden und ich glaube auch eins passend für die Lampe, aber es passiert nichts.
Aktuell ist 1.2.214 installiert. Da die Lampe manchmal im Betrieb kurz dunkel wird, dachte ich ein Update würde das evtl beheben.

Wie geht der zigbe2mqtt Weg?

Danke Euch


Update: Evtl hatte ich mich zu früh gefreut und es gibt gar kein update:

http://fw.ota.homesmart.ikea.net/feed/version_info.json

http://fw.ota.homesmart.ikea.net/global/GW1.0/01.12.031/bin/159696-TRADFRI-bulb-w-1000lm-1.2.214.ota.ota.signed

Beta-User

Bei mir wurde das update durchgefahren. Ein Teil ist aber afaik noch mit 1.2.214 aktuell, da ist nicht alles auf 2.3.050, und m.E. passt der screenshot bzw. der file-Name auch dazu.
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

Doublefant

Vielen Dank für diese Anleitung und die hilfreichen Infos in der laufenden Diskussion.
Ich habe meinen RPi headless laufen und daher keine Möglichkeit über den normalen Weg die Updates anzustoßen.
Ich musste zwar die passenden Linux Befehle erst herausfinden, die leider nicht in der Anleitung enthalten sind, aber letztendlich hat es gut funktioniert.
TOP Foren Community! :D

Jamo

#53
Hallo Doublefant,
kannst Du auch noch teilen, welche Linux Befehle Du benutzt hast, und wie Du es dann gemacht hast?
Ich frage, weil auf der ersten Seite im thread #1 vom 28 Januar 2020, stehen ja alle Befehle, die man für headless braucht, oder?
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

Beta-User

Kleines update: im ersten Post ist jetzt ein modifiziertes "tradfri-script" angehängt, das dann alle bei kkoenk verfügbaren firmware-files nach ~/otau lädt.
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

Jamo

Hallo Carlos,
kannst Du uns nochmal sagen, wie das Update mit zigbe2mqtt funktioniert?
Zitat von: carlos am 24 November 2020, 16:20:46
Hallo,
Den update habe ich auch wochenlang probiert. Hat nie funktioniert.
Habe es dann mit zigbe2mqtt gemacht.
Das ging dann damit recht schnell.

Gruß

Carlos
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

Udomatic

#56
Zitat von: Jamo am 14 Dezember 2021, 10:29:12
Hallo Carlos,
kannst Du uns nochmal sagen, wie das Update mit zigbe2mqtt funktioniert?


Darf man hier Youtube Links teilen? Gibt inzwischen Videos, die anschaulich zeigen, wie es geht, sowohl mit deCONZ als auch mit zigbee2mqtt!
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Beta-User

Zitat von: Udomatic am 15 Dezember 2021, 06:59:56
Darf man hier Youtube Links teilen? Gibt inzwischen Videos, die anschaulich zeigen, wie es geht, sowohl mit deCONZ als auch mit zigbee2mqtt!
...ich habe zwar ein allgemein eher unentspanntes Verhältnis zu manchen Video-"Infos", aber es ist nicht prinzipiell verboten, v.a. dann nicht, wenn es um Info geht und nicht um Werbung für irgendwas Sachfremdes...
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

carlos

Das geht ganz einfach im Web interface von zigbe2mqtt.
OTA, da sind dann deine devices und du kannst prüfen ob ein firmware update da ist.
siehe Bild.
Gruß

Carlos
FHEM svn auf Intel NUC mit proxmox,1 UDOO, 3 Raspberry Pi, signalduino, nanoCUL, div. Homematic Komponenten, toom Baumarkt Funksteckdosen, einige sonoffs, hue, shelly