Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

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

Vorheriges Thema - Nächstes Thema

Mr. P

Hej Andreas,

funktioniert bei mir seit Anfang an ohne Probleme.
Wie hast du denn versucht, die beiden Geräte zu peeren?
Greetz,
   Mr. P

knochenmuehle

set THL peerChan 0 RT_WZ_1_Weather single
allerdings habe ich mit 3 Thermostaten gepeert

Andreas

Mr. P

Zitat von: knochenmuehle am 27 September 2014, 19:02:39
set THL peerChan 0 RT_WZ_1_Weather single
allerdings habe ich mit 3 Thermostaten gepeert
Ja, eben so, wie es sein soll.
Ich habe nur einen RT mit dem Sensor gepeert, kann schon sein, dass es bei der Anzahl zu einem Timing-Problem kommt.
Aber mach am besten einmal ein Listing von deinem Sensor und den Weather_Channel deines/deiner Problem RT(s). Vielleicht sieht man da schon was.
Andernfalls werden wir uns die Raw-Msgs zwischen den Devices einmal näher ansehen müssen.
Aktuelle Versionen hast du auf den beiden Geräten drauf, oder? Also RT mit v1.3 und THPL mit v0.12?
Greetz,
   Mr. P

frank

hallo dirk,

ich habe gerade versucht mir einen neuen ota-bootloader zu bauen. make bricht aber immer mit folgender fehlermeldung ab:

D:\Dokumente und Einstellungen\frank\Eigene Dateien\FHEM\thpl_0.12\Asksin_OTA_Bo
otloader-master>make clean HB_UW_Sen_THPL
rm -rf *.o *.elf *.lst *.map *.sym *.lss *.eep *.srec *.bin *.hex \
        uart/*.o uart/*.elf uart/*.lst uart/*.map uart/*.sym uart/*.lss uart/*.e
ep uart/*.srec uart/*.bin uart/*.hex
make -C ./uart/ MCU=atmega328p
make[1]: Entering directory `D:/Dokumente und Einstellungen/frank/Eigene Dateien
/FHEM/thpl_0.12/Asksin_OTA_Bootloader-master/uart'

-------- begin --------
avr-gcc (WinAVR 20081205) 4.3.2
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Compiling: test_uart.c
avr-gcc -c -mmcu=atmega328p -I. -gdwarf-2 -DF_CPU=8000000UL    -Os -funsigned-ch
ar -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -W
a,-adhlns=test_uart.lst  -std=gnu99 -MD -MP -MF .dep/test_uart.o.d test_uart.c -
o test_uart.o

Compiling: uart.c
avr-gcc -c -mmcu=atmega328p -I. -gdwarf-2 -DF_CPU=8000000UL    -Os -funsigned-ch
ar -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -W
a,-adhlns=uart.lst  -std=gnu99 -MD -MP -MF .dep/uart.o.d uart.c -o uart.o

Linking: test_uart.elf
avr-gcc -mmcu=atmega328p -I. -gdwarf-2 -DF_CPU=8000000UL    -Os -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-
adhlns=test_uart.o  -std=gnu99 -MD -MP -MF .dep/test_uart.elf.d test_uart.o uart
.o --output test_uart.elf -Wl,-Map=test_uart.map,--cref    -lm

Creating load file for Flash: test_uart.hex
avr-objcopy -O ihex -R .eeprom test_uart.elf test_uart.hex

Creating load file for EEPROM: test_uart.eep
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" \
        --change-section-lma .eeprom=0 -O ihex test_uart.elf test_uart.eep
e:\programme\Arduino\hardware\tools\avr\bin\avr-objcopy.exe: --change-section-lm
a .eeprom=0x00000000 never used

Creating Extended Listing: test_uart.lss
avr-objdump -h -S test_uart.elf > test_uart.lss

Creating Symbol Table: test_uart.sym
avr-nm -n test_uart.elf > test_uart.sym
-------- end --------

make[1]: Leaving directory `D:/Dokumente und Einstellungen/frank/Eigene Dateien/
FHEM/thpl_0.12/Asksin_OTA_Bootloader-master/uart'
avr-gcc -Wall -c -std=c99 -mmcu=atmega328p -Wl,--section-start=.text=0x7000,--se
ction-start=.addressDataType=0x7FF0,--section-start=.addressDataSerial=0x7FF2,--
section-start=.addressDataId=0x7FFC -DF_CPU=8000000 -DHB_UW_Sen_THPL -Os cc.c -o
cc.o
avr-gcc -Wall    -std=c99 -mmcu=atmega328p -Wl,--section-start=.text=0x7000,--se
ction-start=.addressDataType=0x7FF0,--section-start=.addressDataSerial=0x7FF2,--
section-start=.addressDataId=0x7FFC -DF_CPU=8000000 -DHB_UW_Sen_THPL -DCODE_LEN=
0x6FFE -Os bootloader.c cc.o uart/uart.o -o Bootloader-AskSin-OTA-HB_UW_Sen_THPL
.elf
e:/programme/arduino/hardware/tools/avr/bin/../lib/gcc/avr/4.3.2/../../../../avr
/bin/ld.exe: section .addressDataType [00007ff0 -> 00007ff1] overlaps section .t
ext [00007000 -> 0000819d]
make: *** [hex] Error 1


was kann ich tun?

gruss frank
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Dirk

Zitat von: frank am 27 September 2014, 19:13:19
overlaps section .text [00007000 -> 0000819d]
Das bedeuted dass das Kompilat des Bootloaders zu groß ist, und in die Section für den Adressbereich hinein recht bzw. auch weiter.
Hast du noch Änderungen am Code vorgenommen.

Du kannst auch den fertig kompilierten Bootloader benutzen. Ich kann dir das Flash-Tool schicken mit dem du während des Flashens die Seriennummer, HM-ID usw. ändern kannst.

Zitat von: Mr. P am 27 September 2014, 18:53:00
funktioniert bei mir seit Anfang an ohne Probleme.
Klaüpt mit v0.12 die Kommunikation hier auch noch reibungslos?

Mr. P

#1100
Zitat von: Dirk am 27 September 2014, 19:22:05
Klaüpt mit v0.12 die Kommunikation hier auch noch reibungslos?
War mir jetzt auch nicht sicher... aber gerade nachgesehen und ja, auch seit dem Update gibt es keinen einzigen Ausreißer bei den Logdaten vom RT. :-)

Edit: Batterie logge ich seit dem Update auch in einigen Varianten (v0.11 ohne Peering, v0.12 ohne Peering, v0.12 mit Peering) mit und da zeichnet sich auch schon ein klarer Trend zum geringeren Stromverbrauch ab. Will es aber noch ein paar Tage laufen lassen, bevor ich die Zahlen veröffentliche. ;-)
Greetz,
   Mr. P

frank

ZitatHast du noch Änderungen am Code vorgenommen.
ich habe nur die "HB-UW-Sen-THPL.h" angepasst:

// The model type
//#define HM_TYPE              0xF1, 0x01    // DIY (HB-UW-Sen-THPL-I) // stored at 0x7FF0
#define HM_TYPE              0xF1, 0x01 // stored at 0x7FF0

// 10 bytes serial number. Must be unique for each device
#define HM_SERIAL            'U','W','S','4','2','0','2','9','0','3' // stored at 0x7FF2

// 3 bytes The device address (hm_id)
#define HM_ID                0x83, 0x76, 0x5A // stored at 0x7FFC


zuerst hatte ich den fertigen bootloader geflasht. da beim anschliessenden ota-update mit eq3-sw am ende ein problem war, hatte ich gedacht, dass es an den default einstellungen gelegen hätte. deswegen der eigenbau.

ZitatDu kannst auch den fertig kompilierten Bootloader benutzen. Ich kann dir das Flash-Tool schicken mit dem du während des Flashens die Seriennummer, HM-ID usw. ändern kannst.
das wäre natürlich auch prima.

gruss frank
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Dirk

Zitat von: frank am 27 September 2014, 19:38:38
ich habe nur die "HB-UW-Sen-THPL.h" angepasst:
Ich vermute dass deine Version vom Compiler etwas größeren Code erzeugt.
Was für eine Version benutzt du denn?


Anbei mal das Flash-Tool.
Allerdings aktuell nur für Windows. Eine Portierung auf Linux kommt noch.

Aufgerufen wird das ganze so:
Zitat
flash.cmd <programmer> <hexfile> [<HM-TYPE> <HM-ID> <Serial>]

Beispiel:
flash.cmd usbasp WetterSensor+AskSinBootloader_HB-UW-Sen-THPL.hex F1:01 AB:CD:EF UWS1234567

Mit dem Tool kann man aktuell den Bootloader nicht alleine flashen. Das liegt an der Art wie ich die Adressdaten im Hex-File ersetze.
Aktuell braucht man ein Kombiniertes Hex-File. Also Programmcode+Bootloader. Daher ist das Teil auch nicht nicht im Github.

Im Zip ist je ein Hex-File für den AskSin Bootloader Version 0.6.1 und für den seriellen Bootloader.
Beide Bootloader unterstützen die Ablage der Adressdaten im Bootloaderbreich.

Wie gesagt, bestehen die Hexfile aus dem Bootloader und der Firmware. Allerdings noch in einer älteren Version. Und einer Version in dem der Sensor alle 10 Sekunden sendet. Das benutze ich zum Testen der sensoren. Nach dem Flashen muss also noch einmal die gewünschte Firmware dann über OTAU oder den Seriellen Weg eingespielt werden.

ACHTUNG:
Das Tool setzt auch gleich die Fuse-Bits für den Atmega328p. Das könnte man im cmd-file aber ändern.
Das Tool also bitte erstmal nicht für einen anderen AVRs benutzen. Ansonsten kann es sein, dass man sich die Fuses verstellt.

Gruß
Dirk

frank

ZitatIch vermute dass deine Version vom Compiler etwas größeren Code erzeugt.
Was für eine Version benutzt du denn?
alles was arduino 1.05 mit sich bringt. in der fehlermeldung von vorhin steht:

avr-gcc (WinAVR 20081205) 4.3.2
Copyright (C) 2008 Free Software Foundation, Inc.


das flashtool werde ich dann mal probieren. vielen dank bis dahin.

gruss frank
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Dirk

Zitat von: frank am 27 September 2014, 20:24:27
avr-gcc (WinAVR 20081205) 4.3.2
Copyright (C) 2008 Free Software Foundation, Inc.

Das könnte für den größeren Code verantortlich sein. Ich habe hier:
avr-gcc (WinAVR 20100110) 4.3.3

frank

#1105
hallo dirk,

kurze frage. mein programmer ist ein arduino mega 2560 den ich folgendermassen mit avrdude aufrufe:

avrdude -p m328p -P \\.\com62 -b 19200 -c avrisp -V -U flash:w:Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex

was genau muss ich in diesem fall für <programmer> im aufruf von flash.cmd eingeben? nur avrisp?

edit:
wie schon vermutet, erwartet flash.cmd den programmer an com1.

gruss frank
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Dirk

Mist es gibt je noch ein paar Programmer die noch Parameter brauchen. Das muss ich später noch anpassen.

Versuch es mal so:

flash.cmd "avrisp" WetterSensor+AskSinBootloader_HB-UW-Sen-THPL.hex F1:01 AB:CD:EF UWS1234567


Vorher bitte noch die CFG-Datei anpassen:
bin/avrdude.conf

Zeile 318:
default_serial     = "com62";


Hinter Zeile 434 noch diesen Eintrag anhängen (im Abschnitt programmer - id  "avrisp"):
baudrate = 19200

Dann sollte es klappen

frank

jetzt hat alles bestens funktioniert. danke
v0.12 konnte ich jetzt mit eq3-sw updaten. luftdruck hat jetzt eine nachkommastelle.

wer es nachmachen möchte, sollte noch ein semicolon spendieren. also in avrdude.conf folgendes einfügen:

baudrate = 19200;

meinen arduino habe ich an die markierten pins aus dem angehängten bild angeschlossen. und zwar folgendermassen:

sensor        arduinomega (pin)

GND                 GND
RESET               (53)
VCC                  3,3V
SCK                  (52)
MISO                 (50)
MOSI                 (51)

gruss frank
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

hexenmeister

Dies könnte ins Wiki.

Hier gleich auch die Pins für UNO:







ISP     Arduino Mega    Arduino UNO
RST5310
MOSI5111
MISO5012
SCK5213
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

dampf123

Hallo zusammen,
nach dem Firmwareupdate auf 0.12 zeigt mein Innensensor keine Helligkeit mehr an. Der Außensensor schon ......
Hat jemand eine Idee woran das liegen könnte ?

Gruß
Klaus
RPi V2 mit LCD und CSM FW1.57
HM-WDS40-TH-I, HM-LC-SW4-DR, HM-SCI-3-FM, HM-CC-RT-DN