Der deCONZ-firmware-update-Thread

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

Vorheriges Thema - Nächstes Thema

Beta-User

Hallo zusammen,

eigentlich gehört das ganze ja gar nicht hierher, sondern auf die Dresden Elektronik-Seiten, aber auf "besonderen" Wunsch versuche ich hier mal den mir bekannten Stand der Dinge zu konsolidieren, was OTA-updates mit deCONZ angeht.

Ziele sind:

- ota-updates mit deCONZ - (wie) geht das ohne GUI
- wo bekommt man update-files her, welche Methode funktioniert bei welchem Hersteller...

Auf die Schnelle der bisherige Stand:
Zitat von: Beta-User am 28 Januar 2020, 09:19:53
Hmm, bisher dachte ich, man braucht die GUI für firmware-updates, ABER:

Zwischenzeitlich habe ich da Zweifel :) , nachdem mein kleines Experiment auf meinem FHEM-Server angelaufen ist, auf dem auch deconz (headless) läuft...

0. Festgehalten, welche firmware-Versionen FHEM grade kennt: "list TYPE=HUEDevice swversion" => rauskopiert und abgespeichert...

1. Festgestellt, unter welchem user deconz läuft (mit top; das zeigt btw. auf meiner 2-Kern-AMD-Murmel einen Speicherverbrauch und Last an, die etwa dem entspricht, was auch FHEM verursacht).

2. Im home-Verzeichnis dieses users ein Verzeichnis ~/otau angelegt, mit wget das ikea-script geholt (Rechte müssen passen, am einfachsten als dieser user arbeiten; script: https://raw.githubusercontent.com/dresden-elektronik/deconz-rest-plugin/master/ikea-ota-download.py) und ausführbar gemacht.

3. Als dieser user "python ikea-ota-download.py" ausgeführt (mußte keine alte Python-Version installieren).

4. Dann findet man eine ganze Anzahl von Dateien in dem "otau"-Verzeichnis.

5. "sudo service deconz restart"
Führt dazu, dass man eine ganze Menge zusätzlicher files in dem "otau"-Verzeichnis findet => deconz "sieht" die updates  :)

6. Jetzt bin ich grade mal am schauen, ob die updates auch alle durchgeführt werden, wenn man jeweils die Geräte neu einschaltet (Stromzufuhr unterbrechen bzw. Batterie raus und rein). Wird dauern, bis Ergebnisse vorliegen, ein großer Teil der firmwares schien aktuell zu sein.

Zitat von: Beta-User am 28 Januar 2020, 10:29:36
Was OTA-files angeht, ist das Bild gemischt:

* HUE: https://github.com/dresden-elektronik/deconz-rest-plugin/issues/270 (scheint "irgendwie" zu gehen, wenn man die richtige URL errät => großer Mist, aber Hoffnung in Sicht! (Ich habe aber keine HUE, ist nur Theorie...))
* Osram: https://phoscon.de/en/support#ota-update-osram-devices führt zu https://update.ledvance.com/firmware-overview?submit=all
=> sieht stressfrei aus, es wird aber auf den GUI-update verwiesen (dto: keine Geräte vorhanden)
* zu Xiaomi, tint und innr habe ich bislang nichts gefunden...

Meine Xiaomi-firmwares sind verdächtig alt (temp/hum: 20161129, Bewegungsmelder 20170627), die innr (SP 120) zeigen 2.0, ebenso die  tint (9W, mit Farbtemperatur, angezeigt als "MLI" - "Extended color light").

Was dann noch interessant wäre: Der Jung-support hatte ein update für den ZLL 5004 (8-fach-Taster) für Januar angekündigt, das könnte auch für andere insta-Varianten interessant sein. Bislang ist auf der Jung-homepage aber nichts zu finden.

Wer also weitere sachdienliche Hinweise hat: pls post...

Grüße, Beta-User



EDIT:
1. Bin nicht in allen Fällen sicher, ob das auch zu deconz paßt, aber die mWn. derzeit vollständigste Liste für ZigBee-OTA-files bzw. deren Quellen ist unter https://github.com/Koenkk/zigbee-OTA zu finden.

2. Man kann auch auf headless-Systemen deconz-GUI starten, indem man den X-Server per ssh durchreicht. Habe das irgendwo auch mal detaillierter aufgeschrieben gehabt (vermutlich irgendwo in dem "unboxing"-Thread), im Prinzip hatte ich dazu aber nur die Anleitung unter https://wiki.ubuntuusers.de/SSH/#X-Forwarding befolgt und dann den deconz-Service gestoppt, deconz-GUI gestartet, und nach "Gebrauch" dann wieder den umgekehrten Weg genommen...



EDIT2: Um alle files sowohl für tradfri wie auch für die aus https://github.com/Koenkk/zigbee-OTA auf einen Rutsch runterzuladen kann man das im Anhang befindliche script benutzen.
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

MadMax-FHEM

Super!

Dann hänge ich mich mal hier dran :)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

justme1968

wäre das im wiki nicht besser aufgehoben?
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Beta-User

Zitat von: justme1968 am 28 Januar 2020, 12:28:28
wäre das im wiki nicht besser aufgehoben?
Am Ende: ja...

Im Moment ist das ja eher noch in einem frühen Experimentierstadium, zumindest, was mich angeht ::) .
(Falls sich nicht DE entscheidet, das zu konsolidieren und dann auch aktuell zu halten (!); das wäre noch besser, denn dann wäre es da, wo es eigentlich hingehört  ;D ...)

[OT]
Im Wiki wäre dann auch gut aufgehoben, was man sonst so zum Thema ZigBee weiß, z.B. zickende Scene-Controler (Taster, ich vermute, der hier ist ebenfalls von insta, wie mein Jung ZLL 5004)) und solche, die sowohl kaum Probleme machen und in gängige Schalterprogramme passen, welche Hersteller es gibt, die Dinge anbeiten, v.a. solche, die in europäische Dosen passen  (schon mal von lupus gehört?) usw. usf...
Kurz: das füllt nicht nur einen Abend ;D . Vielleicht hat aber zur Abwechslung auch mal jemand anderes Lust, diese Fleißarbeit zu übernehmen. @ZigBee würde ich mich gerne auf das beschränken, was grade "muß"...
[/OT]
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

CoolTux

Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

MadMax-FHEM

Zitat von: CoolTux am 28 Januar 2020, 13:41:30
Mitlesen

Wusst ich doch, dass es mehrere interessiert ;)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

Zitat von: MadMax-FHEM am 28 Januar 2020, 13:53:32
Wusst ich doch, dass es mehrere interessiert ;)
;D ;D ;D

Das war nie die Frage, sonst hätte ich mir auch nicht die Mühe gemacht, diese "Wissenskrümelchen" wenigstens bis zu diesem Punkt zusammenzutragen und mal konsolidiert (in dem anderen Thread) aufzuschreiben ;) .
Vielleicht revanchiert sich ja jemand mit dem einen oder anderen Tipp ;D .

[OT] auch noch den Rest aus dem anderen Thread:
Zur Konfiguration spezieller Devices mit GUI-Unterstützung - dort wohl ein Ikea-Shutter:
Zitat von: Beta-User am 28 Januar 2020, 09:19:53
Ich wage mal zu behaupten, dass man das auch ohne GUI hinbekommt, die Konfigurationsdaten müssen ja irgendwo stehen (vermute in irgendeiner xml). Wie bei dem OTA-Beispiel scheint das aber entweder jedem klar zu sein, oder es hat schlicht noch niemand dokumentiert...
(Das darf gerne in einem anderen Thread weiterbehandelt werden, geht mich im Moment nix an...)

ZitatIch würde dem TE daher empfehlen, den Server ausreichend zu dimensionieren, was den Speicher angeht, und deCONZ parallel zu installieren. Nur aufpassen, dass sich ggf. die Dinge nicht auf USB-Ebene ins Gehege kommen ("by-id" in FHEM usw.)  ;) ...
Auch das darf gerne an anderer Stelle weiter diskutiert werden, ich füg's nur mal bei, damit "mein" Erkenntnisstand zum Thema deCONZ fast vollständig hier steht... Fehlt nur noch
- die "Nicht mehr docker"-Geschichte, aber die habe ich vor langem mal irgendwo anders ingeschrieben und
- die ZLL 5004-Amnesie-Odysee, aber auch die steht hier irgendwo ;) .

Aber wie gesagt: Bitte diese Teile woanders besprechen, und wer auch immer mag, darf das gerne Wiki-like aufbereiten :) .
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

binford6000

Ich habe mal nach Firmware Updates für INNR Lightstrips gesucht und habe dabei herausgefunden, dass die nur mit der Original-Bridge upzudaten sind. Hintergrund war das Verwenden der Strips in Deconz Szenen mit andimmen, welche die INNRs aber leider (noch) nicht unterstützen...
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2058

VG Sebastian

Beta-User

Update zu innr und Müller Licht.

Ich habe beide am vergangenen Mittwoch mal angeschrieben und gefragt, ob es zu einem bestimmten Device ein update gibt, und ob man das ggf. z.B. mit deCONZ aufspielen könnte, wie bei anderen Produkten anderer Hersteller auch. (Zwischen-) Ergebnisse:

- der innr Service ist sehr responsive, binnen eines Tages erhält man Antworten. Stand ist der, dass nach wie vor updates wenn, dann nur über deren eigene Bridge gehen würden. Es gäbe bislang auch keine updates, insbesondere die SP 120 wurde nie mit einer anderen Version als 2.0 verkauft. Eine API für die (ziemlich teure) innr-Bridge (bzw. eine Beschreibung dafür) gibt es nicht.
(Fazit: Schade! Aber mal sehen, vielleicht brauchen die einfach etwas Bedenkzeit zu den Themen; mMn. ist deren Marktanteil zu gering, um da in der Defensive bleiben zu können...!).

- Müller Licht läßt sich Zeit. Bis eben war gar keine Antwort eingetroffen.
(eigentlich ein no-go! Vielleicht muß man auch Aldi&toom dazu mal kontaktieren?!? Die kennen vermutlich das Thema noch gar nicht...)
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

update zum Thema Jung ZLL5005:
Habe die Woche einen link erhalten, update eingespielt, Ergebnisse stehen noch aus.

Scheint so zu sein, dass der Service von Jung den Link nur auf Anforderung rausgibt, das update soll die Batterielebensdauer verkürzen, weil (wohl wg. der Anforderungen seitens Zigbee 3.0) regelmäßige Statusupdates rausgehen müssen.

Etwas irritierend ist, dass ich keine Anzeige der firmware-Version habe, die zu "update done" paßt... Mal sehen...
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

Kurzer Zwischenstand, aus Anlaß dieses Threads (@majestro84: update des zigbee-attrTemplates folgt):

Jedenfalls die ganz großen Probleme mit dem Jung scheinen behoben zu sein, weiß noch nicht, ob ich insgesamt damit zufrieden sein soll, habe noch ein diffus ungutes Gefühl, das aber vermutlich auch damit zusammenhängt, dass meine Leuchten traditionell hinter Schaltern sitzen und etwas Zeit benötigt zu werden scheint, bis sich die Partner wieder gefunden haben... Falls es echte Hänger damit gibt, gibt's wieder ein update.



Eigentlicher Hinweis: In diesem Thread bei zigbee2mqtt gibt es ein paar Links zu ota-update-files weiterer Hersteller, die hier https://github.com/Koenkk/zigbee2mqtt/issues/2921#issuecomment-583769045 drin sind, die im ersten Beitrag teilsweise noch fehlen.

Die Devices habe ich zwar nicht, aber auf "meine Positivliste" kommen daher (jedenfalls vorläufig) noch
- Ubisys: https://www.ubisys.de/en/support/firmware/ (die Dateien haben .zigbee-Endungen, sollte also ohne weiteres gehen)
- Salus: https://eu.salusconnect.io/demo/default/status/firmware?timestamp=0 (komprimierte files, intern mit .ota, erinnert an IKEA (?))

Aufgrund des Formats würde ich mal tippen, dass deCONZ problemlos damit umgehen kann.
Was mir noch unklar ist: Ob es (nur bei Netzbetriebenen Geräten) so ist, dass deCONZ Dateien, die im Verzeichnis ~/otau des Users, unter dem deconz läuft, als ota-files erkennt, ggf. auspackt und an die Geräte verschickt?

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

volschin

Man sollte mal erwähnen, dass es gestern aus meiner Sicht einen Durchbruch beim OTAU-Plugin für die Hue-Firmwares gab.  :)
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/270

Das dürfte all jene interessieren, die ihre Hue Lampen nur deshalb noch an der Hue-Bridge haben, um die Firmware-Updates zu bekommen.
Intel NUC+Ubuntu 22.04+Docker+FHEM6
HomeMatic: HM-MOD-RPI-PCB+HM-USB-CFG2+hmland+diverse, HUE: Hue-Bridge, RaspBee+deCONZ+diverse
Amzn Dash-Buttons, Siro Rollos
4xRPi, 4xCO20, OWL+USB, HarmonyHub, FRITZ!Box 7590, Echo Dots+Show8, Logi Circle 2, HomeBridge
TIG Stack (Telegraf, InfluxDB, Grafana)

eisenhauer1987

Zitat von: Beta-User am 07 März 2020, 13:53:45
update zum Thema Jung ZLL5005:
Habe die Woche einen link erhalten, update eingespielt, Ergebnisse stehen noch aus.

Scheint so zu sein, dass der Service von Jung den Link nur auf Anforderung rausgibt, das update soll die Batterielebensdauer verkürzen, weil (wohl wg. der Anforderungen seitens Zigbee 3.0) regelmäßige Statusupdates rausgehen müssen.

Etwas irritierend ist, dass ich keine Anzeige der firmware-Version habe, die zu "update done" paßt... Mal sehen...

Hi,

ich habe mit einem zweiten Jung schalter auch das disconnect problem, kannst du mir den Link schicken?

Grüße

Beta-User

Im Zweifel bitte direkt an den Support von Jung wenden.

Es kann nicht schaden, wenn sich dort "Betroffene" melden. Ich bin übrigens noch nicht sicher, ob das update wirklich alle Probleme behebt. Ich hatte wieder Ausfälle, wenn auch nicht so schnell... Werde das voraussichtlich auch nochmal an Jung zurückspiegeln, dann aber hoffentlich gleich mit "ein paar netten Anmerkungen" zu dem, was die Konkurrenz "kann".

Dazu noch etwas OT-Hintergrund:
Ich habe noch einen 6-Tasten Xiaomi "opple" hier rumliegen. Wenn der vollends @deCONZ funktioniert, ist der vermutlich um Welten besser als der Jung!
Ich wollte den ursprünglich testweise in meine Jung-CD500-Installation reinpfriemeln, aber das Teil ist so elegant (und mit Doppel- und Dreifachklicks (?) sehr viel funktionaler!), das ich den voraussichtlich "standalone" irgendwo ranpappen werde und (funktional) einen HM-Taster damit ersetzen, der sowieso an einer etwas ungeschickten Stelle in das Schalterprogramm "integriert" ist...

Hat nur den Nachteil (und damit zurück zu diesem Thread  ;) ), dass wir zu Xiaomi bisher ebenfalls keine OTA-Info haben. Oder weiß da jemand was zu?
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

volschin

Nach den Infos aus dem Netz ist bisher nicht bekannt, das Xiaomi überhaupt Firmwareaktualisierungen anbietet. Auch bei Einsatz eigener Gateways sind die bekannten Firmware-Stände unverändert.
Intel NUC+Ubuntu 22.04+Docker+FHEM6
HomeMatic: HM-MOD-RPI-PCB+HM-USB-CFG2+hmland+diverse, HUE: Hue-Bridge, RaspBee+deCONZ+diverse
Amzn Dash-Buttons, Siro Rollos
4xRPi, 4xCO20, OWL+USB, HarmonyHub, FRITZ!Box 7590, Echo Dots+Show8, Logi Circle 2, HomeBridge
TIG Stack (Telegraf, InfluxDB, Grafana)