Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

Begonnen von trilu, 23 Februar 2014, 12:23:22

Vorheriges Thema - Nächstes Thema

cactus-online

Zitat von: Dirk am 22 September 2014, 11:00:57
Ich habe hier schon ein paar Sachen probiert.
Aktuell schein es so, dass die CCU2 nicht mit Geräten zurecht kommt bei denen man den Bootloader manuell starten muß.
Oder ich bekomme das aktuell nicht hin.
Ich teste hier aber noch weiter.

Kann ich denn das Flash-Tool-Linux_RaspberryPi.tgz mit CUL auf einer CCU2 benutzen ?

Dirk

Zitat von: cactus-online am 22 September 2014, 16:47:44
Kann ich denn das Flash-Tool-Linux_RaspberryPi.tgz mit CUL auf einer CCU2 benutzen ?
Also du hast einen CUL für CUXd an deiner CCU2?
Theoretisch sollte das funktionieren. Es könnte sogar sein, dass die Binaries vom Raspberry Pi so auf der CCU2 direkt laufen.
Du müsstest halt den CUXd vorher stoppen damit der CUL frei ist.

santalaus

Hallo,

bin ich Blind oder ist es ein Fehler bei mir, das ich fwUpdate nicht als Option bei set auswählen kann?

Nico

Dirk

Zitat von: santalaus am 22 September 2014, 18:33:46
bin ich Blind oder ist es ein Fehler bei mir, das ich fwUpdate nicht als Option bei set auswählen kann?
Ich vermute ich habe hier noch eine Magische Einstellung vergessen.
Ich schau mir das noch mal an.
Bis dahin könntest du das Update über das OTA-Tool durchführen.

knochenmuehle

#1054
was läuft falsch ?
FHEM ist gestoppt. diese Meldungen bekomme ich:

root@cubie:/opt/hmcfgusb# ./flash-ota -f HB-UW-Sen-THPL_update_V0_12_001_140922.eq3 -s UWS9333135
HomeMatic OTA flasher version 0.097-git

Reading firmware from HB-UW-Sen-THPL_update_V0_12_001_140922.eq3...
Firmware with 225 blocks successfully read.

Rebooting HM-CFG-USB to avoid running out of credits

HM-CFG-USB not in bootloader mode, entering bootloader.
Waiting for device to reappear...
Can't find/open hmcfgusb!
Can't find/open hmcfgusb!
HM-CFG-USB in bootloader mode, rebooting
Can't find/open hmcfgusb!
Can't find/open hmcfgusb!


HM-CFG-USB opened

HM-CFG-USB firmware too low: 964 < 967


Gruß Andreas

Update: HM-CFG-USB braucht ein FW Update ... mal sehen

Update 2: alles gut, nach FW Update des HM-CFG-USB auf 967 hat alles geklappt

BigMac

Hallo Dirk,
kannst Du mir bitte auch Infos zur Sammelbestellung/Beschaffung senden? Vielen Dank!

Mfg

Thomas

Markus

Raspberry Pi2 als FHEM-Plattform
HM, FS20, 1-Wire, PanStamp,LW12,Intertechno,ESPEasy,Alexa

hexenmeister

OTA Update ist ja cool  8)
6 Sensoren OTA upgedated und einen 'per wire'.  Alles läuft. Ich werde bei Gelegenheit auch den mit Seriel-Bootloader mit dem OTAU versorgen ;)
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Dirk

Zitat von: santalaus am 22 September 2014, 18:33:46
bin ich Blind oder ist es ein Fehler bei mir, das ich fwUpdate nicht als Option bei set auswählen kann?
Ich habe im Github-Release das .pm-File angepasst.
fwUpdate und getSerial sind im Modul nun verfügbar.

ABER:
Leider klappt das OTA-Update nicht per FHEM. Mit dem flash-ota aud dem hmcfgusb Paket klappt es hingegen ausgezeichnet.
Hier mal ein Auschnitt aus dem Log vom Update-Versuch über FHEM. Vielleicht hat ja jemand eine Idee:

2014.09.22 21:28:33.509 2: CUL_HM fwUpdate CUL_HM_HB_UW_Sen_THPL_I_112233 entered mode. IO-speed: fast
2014.09.22 21:28:33.610 4: CUL_send:  CULAs 0F 0B 00CB 1ACAE5 112233 105B11F81547
2014.09.22 21:28:33.681 4: CUL_send:  CULAR
2014.09.22 21:28:33.764 4: CUL_send:  CULAs 27 0D 00CA 1ACAE5 112233 00800C948A000C94A42D0C94D12D0C9456100C9431100C940C100C948414
2014.09.22 21:28:33.783 4: CUL_send:  CULAs 27 0E 00CA 1ACAE5 112233 0C94B2000C94B2000C94B2000C94B2000C94B2000C94B2000C94B2000C94
2014.09.22 21:28:33.806 4: CUL_send:  CULAs 27 0F 00CA 1ACAE5 112233 B2000C94B2000C94142E0C94B2000C94BB2B0C94092C0C94B2000C94B200
2014.09.22 21:28:33.817 4: CUL_send:  CULAs 27 10 00CA 1ACAE5 112233 0C94B2000C94B2000C9420030C94B2000000000005000000009801010406
2014.09.22 21:28:33.827 4: CUL_send:  CULAs 13 11 20CA 1ACAE5 112233 0501050000009D010063
2014.09.22 21:28:33.838 4: CUL_Parse: CUL A 0A 0D 8002 112233 1ACAE5 8040 -42
2014.09.22 21:28:33.838 4: CUL_Parse: CUL A 0A 0E 8002 112233 1ACAE5 8040 -42
2014.09.22 21:28:33.857 4: CUL_Parse: CUL A 0A 0F 8002 112233 1ACAE5 8041 -41.5
2014.09.22 21:28:33.861 4: CUL_Parse: CUL A 0A 11 8002 112233 1ACAE5 8041 -41.5
Use of uninitialized value $mNo in sprintf at /opt/FHEM/fhem.dev/FHEM/10_CUL_HM.pm line 5331.
2014.09.22 21:28:38.843 4: CUL_send:  CULAs 27 01 00CA 1ACAE5 112233 00800C948A000C94A42D0C94D12D0C9456100C9431100C940C100C948414
2014.09.22 21:28:38.856 4: CUL_send:  CULAs 27 02 00CA 1ACAE5 112233 0C94B2000C94B2000C94B2000C94B2000C94B2000C94B2000C94B2000C94
2014.09.22 21:28:38.872 4: CUL_send:  CULAs 27 03 00CA 1ACAE5 112233 B2000C94B2000C94142E0C94B2000C94BB2B0C94092C0C94B2000C94B200
2014.09.22 21:28:38.890 4: CUL_send:  CULAs 27 04 00CA 1ACAE5 112233 0C94B2000C94B2000C9420030C94B2000000000005000000009801010406
2014.09.22 21:28:38.902 4: CUL_send:  CULAs 13 05 20CA 1ACAE5 112233 0501050000009D010063
2014.09.22 21:28:38.949 4: CUL_Parse: CUL A 0A 05 8002 112233 1ACAE5 8051 -33.5
Use of uninitialized value $mNo in sprintf at /opt/FHEM/fhem.dev/FHEM/10_CUL_HM.pm line 5331.
2014.09.22 21:28:43.946 4: CUL_send:  CULAs 27 01 00CA 1ACAE5 112233 00800C948A000C94A42D0C94D12D0C9456100C9431100C940C100C948414
2014.09.22 21:28:43.965 4: CUL_send:  CULAs 27 02 00CA 1ACAE5 112233 0C94B2000C94B2000C94B2000C94B2000C94B2000C94B2000C94B2000C94
2014.09.22 21:28:43.980 4: CUL_send:  CULAs 27 03 00CA 1ACAE5 112233 B2000C94B2000C94142E0C94B2000C94BB2B0C94092C0C94B2000C94B200
2014.09.22 21:28:43.995 4: CUL_send:  CULAs 27 04 00CA 1ACAE5 112233 0C94B2000C94B2000C9420030C94B2000000000005000000009801010406
2014.09.22 21:28:44.012 4: CUL_send:  CULAs 13 05 20CA 1ACAE5 112233 0501050000009D010063
Use of uninitialized value $mNo in sprintf at /opt/FHEM/fhem.dev/FHEM/10_CUL_HM.pm line 5331.
2014.09.22 21:28:49.028 4: CUL_send:  CULAs 27 01 00CA 1ACAE5 112233 00800C948A000C94A42D0C94D12D0C9456100C9431100C940C100C948414
2014.09.22 21:28:49.070 4: CUL_send:  CULAs 27 02 00CA 1ACAE5 112233 0C94B2000C94B2000C94B2000C94B2000C94B2000C94B2000C94B2000C94
2014.09.22 21:28:49.083 4: CUL_send:  CULAs 27 03 00CA 1ACAE5 112233 B2000C94B2000C94142E0C94B2000C94BB2B0C94092C0C94B2000C94B200
2014.09.22 21:28:49.101 4: CUL_send:  CULAs 27 04 00CA 1ACAE5 112233 0C94B2000C94B2000C9420030C94B2000000000005000000009801010406
2014.09.22 21:28:49.112 4: CUL_send:  CULAs 13 05 20CA 1ACAE5 112233 0501050000009D010063
2014.09.22 21:28:54.129 4: eventTypes: CUL_HM CUL_HM_HB_UW_Sen_THPL_I_112233 fwUpdate: fail:Block1 -> fwUpdate: fail:Block1


@BigMac und Markus, ich habe euch die Infos geschickt.

Gruß
Dirk

Mr. P

Zitat von: Dirk am 22 September 2014, 21:57:29
ABER:
Leider klappt das OTA-Update nicht per FHEM. Mit dem flash-ota aud dem hmcfgusb Paket klappt es hingegen ausgezeichnet.
Hier mal ein Auschnitt aus dem Log vom Update-Versuch über FHEM. Vielleicht hat ja jemand eine Idee:
Kann aber hoffentlich Martin demnächst etwas dazu sagen, woran es womöglich scheitert. :-)

An der Stelle jetzt aber auch von mir ein großes Danke für das Update! *thumbsUp*
Habe meine Sensoren jetzt alle geflasht und werde den weiteren Batterieverlauf im Auge behalten. Mal sehen, wie sie sich jetzt nach dem Update tun. ;-)

Eine Frage noch: besteht die Möglichkeit eine Funktion in die Firmware der Sensoren einzubauen, dass sie sich - analog zu den RTs - automatisch zu Flashbeginn neu starten und in den Bootloader begeben?

Nochmals vielen Dank für deine Bemühungen! :-)
Greetz,
   Mr. P

cactus-online

Zitat von: Dirk am 22 September 2014, 17:30:42
Also du hast einen CUL für CUXd an deiner CCU2?
Theoretisch sollte das funktionieren. Es könnte sogar sein, dass die Binaries vom Raspberry Pi so auf der CCU2 direkt laufen.
Du müsstest halt den CUXd vorher stoppen damit der CUL frei ist.

OK, ich check' das mal und berichte dann.

thunder1902

Hallo,

ich verzweifle hier noch...

Hab jetzt endlich mein selbst zusammengebauten Wettersensor mit Firmware "bestücken" wollen.

Nach ettlichen Versuchen bin ich jetzt soweit, dass der Wettersensor.ino - Sketch mit folgender Fehlermeldung abbricht:
WetterSensor.cpp.o: In function `__static_initialization_and_destruction_0':
D:\download-nicht sync\fhem\arduino-1.0.5-r2full2\arduino-1.0.5-r2/WetterSensor.ino:61: undefined reference to `TSL2561::TSL2561()'
AskSin\Sensor_SHT10_BMP085_TSL2561.cpp.o: In function `Sensors_SHT10_BMP085_TSL2561::poll_measure()':
D:\download-nicht sync\fhem\arduino-1.0.5-r2full2\arduino-1.0.5-r2\libraries\AskSin/Sensor_SHT10_BMP085_TSL2561.cpp:48: undefined reference to `Sensirion::meas(unsigned char, unsigned int*, bool)'
D:\download-nicht sync\fhem\arduino-1.0.5-r2full2\arduino-1.0.5-r2\libraries\AskSin/Sensor_SHT10_BMP085_TSL2561.cpp:54: undefined reference to `Sensirion::meas(unsigned char, unsigned int*, bool)'
D:\download-nicht sync\fhem\arduino-1.0.5-r2full2\arduino-1.0.5-r2\libraries\AskSin/Sensor_SHT10_BMP085_TSL2561.cpp:61: undefined reference to `BMP085::begin(unsigned char)'
D:\download-nicht sync\fhem\arduino-1.0.5-r2full2\arduino-1.0.5-r2\libraries\AskSin/Sensor_SHT10_BMP085_TSL2561.cpp:62: undefined reference to `BMP085::readPressure()'
usw....

Kann mir jemand sagen, was ich hier falsch mache?
Ich habe die Libraries in den libraries-Ordner kopiert. Als Arduino IDE setze ich die Version 1.0.5r2 ein.

Alternativ wollte ich die .hex-Dateien von Dirk's Tools/Firmware-Verzeichnis flashen - aber das sind ja nur die Updates!?! Gibt es da auch vollständige Firmware-HEX-Dateien??

Danke schonmal für eure Hilfe!!!!

Dirk

Zitat von: thunder1902 am 23 September 2014, 10:26:08
Nach ettlichen Versuchen bin ich jetzt soweit, dass der Wettersensor.ino - Sketch mit folgender Fehlermeldung abbricht:
Ehrlich gesagt habe ich die letzten Versionen nicht mehr mit der Arduino-IDE kompiliert. Daher will ich hier Fehler nicht ausschließen.
Magst du das mal mit Eclipse probieren und dem Arduino - Plugin? Da die Arduino-IDE nur eine Krücke ist, kann ich das nur empfehlen.


ZitatAlternativ wollte ich die .hex-Dateien von Dirk's Tools/Firmware-Verzeichnis flashen - aber das sind ja nur die Updates!?! Gibt es da auch vollständige Firmware-HEX-Dateien??
Die Hex-Files sind komplett. Die kannst du also direkt flashen. Es wird dann die da eingebaute Default-Seriennummer benutzt. Alternativ flashst du mit dem Flash-Tool und über den seriellen Bootloader, dann kannst du HM-ID und Seriennummer beim Flashen mit angeben.

Dirk

Zitat von: Mr. P am 23 September 2014, 01:12:15
Habe meine Sensoren jetzt alle geflasht und werde den weiteren Batterieverlauf im Auge behalten.
Hast du hier Vergleichswerte von vor dem Update?
Die Sensoren mit den AA-Batterien verhalten sich noch recht unauffällig. Lediglich bei Versorgung mit AAA-Zellen (Aussensensor) sind diese mit der alten FW nach etwa 6-8 Wochen erschöpft.
Bei meinem Außensensor ist das bald wieder so weit, dann bekommt der auch die neue FW. Dann kann ich das direkt vergleichen.

Zitatbesteht die Möglichkeit eine Funktion in die Firmware der Sensoren einzubauen, dass sie sich - analog zu den RTs - automatisch zu Flashbeginn neu starten und in den Bootloader begeben?
Das hatte ich auch noch vor. Allerdings muss man auch dann innerhalb von 10 Sekunden oder so, die Config-Taste drücken.

Da wir hier noch kein AES benutzen können, hatten wir den Bootloader so gebaut dass man diesen zwar per Funk aktivieren kann, man dann aber in einem Zeitfenster trotzdem einmal die Config-Taste drücken muss damit das Flashen startet. Damit soll verhindert werden, dass jemand unbefugtes die Devices "zerflashen" kann.

Mr. P

Zitat von: Dirk am 23 September 2014, 10:51:10
Hast du hier Vergleichswerte von vor dem Update?
Die Sensoren mit den AA-Batterien verhalten sich noch recht unauffällig. Lediglich bei Versorgung mit AAA-Zellen (Aussensensor) sind diese mit der alten FW nach etwa 6-8 Wochen erschöpft.
Bei meinem Außensensor ist das bald wieder so weit, dann bekommt der auch die neue FW. Dann kann ich das direkt vergleichen.
Das hatte ich auch noch vor. Allerdings muss man auch dann innerhalb von 10 Sekunden oder so, die Config-Taste drücken.
Habe leider nur die Innensensoren. Aber zumindest für die hab ich Vergleichswerte, ja. ;-)

Zitat von: Dirk am 23 September 2014, 10:51:10
Da wir hier noch kein AES benutzen können, hatten wir den Bootloader so gebaut dass man diesen zwar per Funk aktivieren kann, man dann aber in einem Zeitfenster trotzdem einmal die Config-Taste drücken muss damit das Flashen startet. Damit soll verhindert werden, dass jemand unbefugtes die Devices "zerflashen" kann.
Achso, ist so beabsichtigt. Gut, dann macht es zumindest für Devices, die man öffnen muss, um an den Config-Button zu kommen, ohnehin wenig Sinn. :-)
Greetz,
   Mr. P