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)

Beta-User

Das ist ja auch schon mal was zu wissen.

Wäre natürlich schön, wenn die sich offiziell "für den Fall der Fälle" äußern würden, aber das ist wohl kaum zu erwarten.
(Vielleicht in dem Zusammenhang noch etwas mehr Klarstellung zum Thema "innr": Auch die hatten das "Problem" bisher nicht, kann also durchaus sein, dass das nicht der Weisheit letzter Schluss war, was mir dazu per Email informell mitgeteilt worden war...).
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

Nachdem das OTA-Plugin von deCONZ ja jetzt netterweise Opensourced wurde, wird ja auch schon fleißig erweitert.
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 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?

Wie hast du Kontakt mit dem Jung Support? Hast du einen Ansprechpartner?

Grüße

Beta-User

Ich meine, schlicht das Kontaktformular auf der Jung-Homepage genutzt und daraufhin dann eine Email mit Ankündigung und dann eine Email von jemandem anderen mit dem Link erhalten zu haben.

Im Zweifel bitte ebenfalls den "offiziellen" Weg wählen!
(Achtung: Ich meine, einmal war der Server nicht erreichbar und der Text dann weg => vorher sicherheitshalber kopieren!).

Vielleicht noch eine Anmerkung: Ich habe einen Link zu Daten erhalten, die seit Jan. oder so da liegen. Was mir allerdings nicht gelungen ist: eine "logische Brücke" zwischen dem Dateinamen und der dann von phoscon angezeigten Firmware-Version zu schlagen.... Vielleicht war das ein Fehler eines einzelnen, vielleicht habe ich irgendwas falsch gemacht, trotz "success"-Rückmeldung, keine Ahnung.
Aber je mehr da direkt rumnerven und per Email "abgefertigt" werden müssen, desto eher evtl. die Neigung, das einfach auf die offizielle Homepage zu nehmen... (verstehe eh' nicht, warum man das nicht macht, man kann doch beide Anbieten und auf eventuelle Nachteile der neuen Fassung hinweisen, das bricht doch niemandem einen Zacken aus der Krone, oder habe ich mal wieder was verpaßt...?). (Oder schreiben, wo Insta das vorhält, falls es ein ip-Thema ist?).
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

pc1246

HP T610
Onkyo_AVR;3 Enigma2; SB_Server ; SB_Player; HM-USB mit 15 HM-CC-RT-DN, 3 HM_WDS10_TH_O, 6 HM-Sec-SCo, 4 HM-Sec-MDIR-2, 1 HM-Sen-MDIR-O-2, 8 Ferion 5000 OW ; PhilipsTV; 4 harmony hub; Jeelink mit 9 PCA301; Somfy; S7-300; 3 LGW; HUE; HM-IP auf Charly

eisenhauer1987

Hier nochmal zu dem Jung Thema für alle. Ich hab das ganze jetzt mal bei 2 Schaltern geflasht. Ich habe jetzt:

1 Schalter alte Firmware, macht nie Probleme, Kauf schon lange her
1 Schalter neue Firmware, machte bisher keine Probleme, Kauf kürzlich
1 Schalter neue Firmware, machte bisher immer wieder Probleme, Kauf kürzlich

Bisher läuft der Test 28h ohne disconnect, ich beobachte das ganze min 2 Wochen. Das war bisher der Bestcase beim Problemgerät.

eisenhauer1987

Zitat von: eisenhauer1987 am 31 März 2020, 19:42:55
Hier nochmal zu dem Jung Thema für alle. Ich hab das ganze jetzt mal bei 2 Schaltern geflasht. Ich habe jetzt:

1 Schalter alte Firmware, macht nie Probleme, Kauf schon lange her
1 Schalter neue Firmware, machte bisher keine Probleme, Kauf kürzlich
1 Schalter neue Firmware, machte bisher immer wieder Probleme, Kauf kürzlich

Bisher läuft der Test 28h ohne disconnect, ich beobachte das ganze min 2 Wochen. Das war bisher der Bestcase beim Problemgerät.

Hi,

es sind jetzt 20 Tage um und alle Schalten laufen zuverlässig!

Spartacus

Hallo,
ich benötige mal Hilfe und finde leider im Web nix dazu.
Ich betreibe ConBee II mit einem Rpi in der Cli-Version und  steuere meine Lämpchen mit fhem. Wollte heute meine IKEA Leuchten mit neuer FW bestücken, da ich Probleme habe. Habe das python Script ausgeführt und nun unter /root das Verzeichnis otau.... Angeblech sollen sich die Leuchten nach Ein/Ausschalten nun automatisch die neue FW ziehen....passiert aber nicht.

Muss das nicht alles unter deCONZ abgelegt sein, damit die neue FW geladen wird? Ich finde das deCONZ auf meinem rpi aber gar nicht.  Kann jemand helfen?

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

slor

Du musst die Lampen stromlos machen...
Fhem auf Raspberry Pi 4
CCU3 mit RaspberryMatic mit HMCCU an FHEM
HMCCU, Telegram, Conbee2 und Hue/Tradfri/Osram Lampen AQARA Sensoren, HomeConnect

Spartacus

Hi,
Zitat von: slor am 22 November 2020, 19:26:20
Du musst die Lampen stromlos machen...
...das habe ich, wie oben, vielleicht etwas undeutlich steht, natürlich gemacht!
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

Beta-User

Mir war das so im Ohr, dass die files in einem bestimmten Verzeichnis in home des users liegen müssen, unter dem deconz dann auch gestartet wird. Dann muss deconz gestartet werden, um das anzustoßen.
Kann aber auch falsch sein oder unvollständig.
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

........danke! Jetzt muss ich nur noch wissen, welches Verzeichnis das ist, und wie man es in seiner Installation findet :(3
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

moskito

Sollte ~/otau sein.
So wird es im Script definiert.

Gruß
Danny
FHEM auf Intel NUC/Proxmox & Debian 12 + HM-CFG-USB + zigbee2mqtt + Zwave + Enocean

rcmcronny

Beim Deconz Image für den PI ist es /home/pi    /es läuft iDR unter dem User "pi" da. Weiss nicht,ob das bei dir auch so ist.

Spartacus

Hallo,
Das war ein guter Hinweis.  Ich habe alles unter root gemacht.  Das kann es dann ja schon sein. Werde das morgen mal unter dem Benutzer pi versuchen......wenn ich das Kennwort noch weiß 😁
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

rcmcronny

Na zur not nach /home/pi/otau verschieben und mit "chown pi:users /home/pi/otau -R" halt dem User geben ^^

Spartacus

#31
Hallo zusammen,
so ich habe die otau-Dateien in das entsprechende Verzeichnis verschoben und auch den Besitzer entsprechend geändert. deconz scheint tatsächlich das Verzeichnis zu sehen....es sind Dateien mit der Endung "zigbee" hinzugekommen (z.B. 117C-4202-12224573.zigbee). Allerdings ändert sich nicht. Die SW-Version der Lichter bleibt gleich und das kann nicht sein. Meine TRADFRI bulb E27 CWS opal 600lm hat SW-Version 1.3.002.

Noch jemand eine Idee, kann es sein, das irgendein Plugin nicht aktiv ist? Bei der GUI-losen Version ist das alles offenbar recht schwierig!
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

Beta-User

Das klingt erst mal gut. Dann ist jedenfalls der update-Prozess an sich losgelaufen.

Aber da war noch was (aus der Erinnerung): Zum einen dauert das ggf. recht lange, bis die updates an alle verteilt sind, und zum anderen kann es sein, dass man die Versionsangaben aktiv anfragen muss (set ... statusRequest (?)).
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

Zitat von: Spartacus am 22 November 2020, 15:14:58
Hallo,
ich benötige mal Hilfe und finde leider im Web nix dazu.
Ich betreibe ConBee II mit einem Rpi in der Cli-Version und  steuere meine Lämpchen mit fhem. Wollte heute meine IKEA Leuchten mit neuer FW bestücken, da ich Probleme habe.

Hast du ein Link für mich, wo man die IKEA FW downloaden kann?
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

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 zusammen,
....da war jemand schneller mit dem Script :-)! Bitte mal Feedback geben, ob das problemlos durchläuft. Bei mir funzt es leider nicht und ich finde auch keine weiteren Hinweise im Netz, wie man das ohne deCONZ Gui ans Fliegen kriegt!

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

Udomatic

Zitat von: Beta-User am 23 November 2020, 16:39:35
Es gibt als Hilfsmittel ein Script dafür: https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/ikea-ota-download.py

Danke, aber ohne Anleitung komme ich mit dem Script leider nicht weit. Gibt es solch eine Online?

Habe schon OTAU Updates für OSARM in deConz durchgeführt. Da hatte ich aber direkt die Firmware Datei genutzt + die entsprechende deConz Anleitung
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

Das script läuft autonom, benötigt wird halt eine Python-Installation. Dann kann man (optimalerweise im Homeverzeichnis des Users, unter dem auch deconz läuft (=bei euch vermutlich "pi")) das script einfach mit wget runterladen (darauf achten, dass der Befehl auf https://raw.githubusercontent.com/dresden-elektronik/deconz-rest-plugin/master/ikea-ota-download.py geht, oder das Ding halt mit einem Editor anlegen), ausführbar machen und mit "python ikea-ota-download.py" starten.

Dann sollten im ~/otau-Verzeichnis diverse (verschlüsselte) Files liegen. Dann deconz neu starten (z.B. mit "sudo service deconz restart"), dann werden es ein paar mehr mit anderer Endung (.zigbee (?)).
Ab da scheiden sich dann die Geister, wie es weitergeht. Ich meine, man muss einfach nur lange genug warten, bis alles dann up-to-date ist; bei dem Jung-Taster hatte ich damals nur die eine File zu übertragen und habe (soweit ich mich entsinne) "Knöpfchen gedrückt", damit das Ding in den Pairing-Modus gegangen ist.

Falls jemand einen Weg kennt, einen Minimal-xserver aufzusetzen, um deCONZ-GUI von einem remote-Rechner aus zu betrachten, feel free, eine Anleitung zu posten... Wäre nicht nur für updates interessant.
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! Bin ein kleines Stückchen weiter...ob es hilft, weiß ich noch nicht.
Auf jeden Fall sollte man im Phoscon WebUI unter Hilfe mal auf die alte WebUI umschalten. Da kann man unter Settings/Advanced Settings den OTAU Server aktivieren....

Vielleicht hilft es ja was! Ich melde mich.
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

Spartacus

Moin zusammen,
das scheint es gewesen zu sein! Die erste Funzel hat ne neue FW....Jetzt werde ich die anderen Lichter auch noch mal stromlos machen und schaue was passiert.

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

Udomatic

Zitat von: Spartacus am 23 November 2020, 17:24:08
Moin,
ich noch mal! Bin ein kleines Stückchen weiter...ob es hilft, weiß ich noch nicht.
Auf jeden Fall sollte man im Phoscon WebUI unter Hilfe mal auf die alte WebUI umschalten. Da kann man unter Settings/Advanced Settings den OTAU Server aktivieren....

Vielleicht hilft es ja was! Ich melde mich.
Spartacus

Das Python Script muss man aber trotzdem ausführen, damit die Files für die FW Updates automatisch geladen werden?

Ich frage mich warum man den OTAU Server nicht über das aktuelle PWA aktivieren kann? Soll das vielleicht nicht mehr sein?
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,

Spartacus

Hi,
ja das Script muss man auf jeden Fall ausführen und zwar als User PI und nicht wie ich es anfangs gemacht habe, als root. Warum das mit dem OTAU Server nur über das alte Web-Interface geht, weiß ich nicht....auf jeden Fall ziehen sich die Leuchten jetzt nach und nach die neue Firmware. Ich frage mich gerade nur, wie das mit den Schaltern geht? Da tut sich aktuell noch nichts!

Wg. Script:
Ich würde das später über einen Scheduler regelmäßig automatisch ausführen wollen...aber erst muss ich den ganzen Conbee-Server noch auf meine neue Qnap in einen Docker-Container packen. Ich hoffe das kriege ich hin!

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

Udomatic

Zitat von: Spartacus am 23 November 2020, 19:18:55

Wg. Script:
Ich würde das später über einen Scheduler regelmäßig automatisch ausführen wollen...aber erst muss ich den ganzen Conbee-Server noch auf meine neue Qnap in einen Docker-Container packen. Ich hoffe das kriege ich hin!

Spartacus

Das ist interessant. Ich würde ConBee auch gerne vom PI los eisen, weil ich immer wieder mal Probleme mit FHEM / Homebridge und ConBee auf einem PI hab.
Gibt es da brauchbare Anleitungen zum Einrichten auf der QNAP?

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,

Spartacus

Hallo
Zitat von: Udomatic am 23 November 2020, 21:17:30
Das ist interessant. Ich würde ConBee auch gerne vom PI los eisen, weil ich immer wieder mal Probleme mit FHEM / Homebridge und ConBee auf einem PI hab.
Gibt es da brauchbare Anleitungen zum Einrichten auf der QNAP?
das weiß ich noch nicht, die TVS-672XT ist bestellt und dann muss ich mir das erst mal anschauen. deCONZ und fhem sollen dann in ein docker-Image. Das wird aber sicherlich noch etwas dauern, bis das am Start ist....

Aber noch mal zum eigentlichen Problem: Gibt es jemanden, bei dem die IKEA Schalter sich auch eine neue FW gezogen haben? Muss man die Dinger auch stromlos machen, sprich die Batterie raus und wieder rein, oder wir läuft das?

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

Udomatic

Hi,

hinter diesem Link verbergen sich direkt Download Links zu den IKEA .ota Firmware Files. Das File in einem Editor öffnen und URL kopieren. Download klappt.

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

Was mir gerade schwer fällt ist die Zuordnung der Files zu Devices. Das matcht nicht zu den Namen in der deConz Gui. Ich weiß z.B. gerade nicht, welche Datei ich für die E14 Bulbs nehmen müsste, vermute diese hier:
TRADFRI-bulb-ws-2.3.050.ota

Damit wäre aber über das STD OTAU Plugin direktes updaten möglich, wie bei den OSRAM Devices.
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

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