Autor Thema: Der deCONZ-firmware-update-Thread  (Gelesen 2590 mal)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 10369
  • eigentlich eher "user" wie "developer"
Der deCONZ-firmware-update-Thread
« am: 28 Januar 2020, 11:27:07 »
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:
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.

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
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline MadMax-FHEM

  • Hero Member
  • *****
  • Beiträge: 7496
  • NIVEAu ist keine Creme...
Antw:Der deCONZ-firmware-update-Thread
« Antwort #1 am: 28 Januar 2020, 12:01:04 »
Super!

Dann hänge ich mich mal hier dran :)

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

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 20260
Antw:Der deCONZ-firmware-update-Thread
« Antwort #2 am: 28 Januar 2020, 12:28:28 »
wäre das im wiki nicht besser aufgehoben?
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH
Zustimmung Zustimmung x 1 Liste anzeigen

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 10369
  • eigentlich eher "user" wie "developer"
Antw:Der deCONZ-firmware-update-Thread
« Antwort #3 am: 28 Januar 2020, 12:39:39 »
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-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 25248
Antw:Der deCONZ-firmware-update-Thread
« Antwort #4 am: 28 Januar 2020, 13:41:30 »
Mitlesen
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://paypal.me/pools/c/8gULisr9BT
My FHEM Git: https://git.cooltux.net/FHEM/
Mein Dokuwiki:
https://www.cooltux.net

Offline MadMax-FHEM

  • Hero Member
  • *****
  • Beiträge: 7496
  • NIVEAu ist keine Creme...
Antw:Der deCONZ-firmware-update-Thread
« Antwort #5 am: 28 Januar 2020, 13:53:32 »
Mitlesen

Wusst ich doch, dass es mehrere interessiert ;)

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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 10369
  • eigentlich eher "user" wie "developer"
Antw:Der deCONZ-firmware-update-Thread
« Antwort #6 am: 28 Januar 2020, 14:05:45 »
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:
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...)

Zitat
Ich 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-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline binford6000

  • Tester
  • Hero Member
  • ****
  • Beiträge: 1241
  • 🏠⚙️💡🛠📱
Antw:Der deCONZ-firmware-update-Thread
« Antwort #7 am: 28 Januar 2020, 22:00:10 »
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
Proxmox mit: nextcloud, fhem, pihole, docker, bitwarden, deconz, TasmoAdmin
fhem mit: deconz, SONOS, alexa-fhem, homebridge, TelegramBot mit msgDialog, livetracking
Testumgebung: docker pull fhem/fhem

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 10369
  • eigentlich eher "user" wie "developer"
Antw:Der deCONZ-firmware-update-Thread
« Antwort #8 am: 03 Februar 2020, 16:55:07 »
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-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}
Zustimmung Zustimmung x 1 Liste anzeigen

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 10369
  • eigentlich eher "user" wie "developer"
Antw:Der deCONZ-firmware-update-Thread
« Antwort #9 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...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 10369
  • eigentlich eher "user" wie "developer"
Antw:Der deCONZ-firmware-update-Thread
« Antwort #10 am: 12 März 2020, 16:01:37 »
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-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline volschin

  • Hero Member
  • *****
  • Beiträge: 1566
Antw:Der deCONZ-firmware-update-Thread
« Antwort #11 am: 14 März 2020, 08:45:55 »
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 20.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+Show5, Logi Circle 2, HomeBridge
TIG Stack (Telegraf, InfluxDB, Grafana)
Zustimmung Zustimmung x 1 Liste anzeigen

Offline eisenhauer1987

  • Jr. Member
  • **
  • Beiträge: 62
Antw:Der deCONZ-firmware-update-Thread
« Antwort #12 am: 30 März 2020, 08:43:08 »
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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 10369
  • eigentlich eher "user" wie "developer"
Antw:Der deCONZ-firmware-update-Thread
« Antwort #13 am: 30 März 2020, 10:42:12 »
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-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline volschin

  • Hero Member
  • *****
  • Beiträge: 1566
Antw:Der deCONZ-firmware-update-Thread
« Antwort #14 am: 30 März 2020, 11:03:31 »
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 20.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+Show5, Logi Circle 2, HomeBridge
TIG Stack (Telegraf, InfluxDB, Grafana)

 

decade-submarginal