Neue Firmware für HM_LC_Sw1PBU_FM mit getrenntem Aktor, Taster + Wechselschalter

Begonnen von jab, 29 Dezember 2013, 22:04:10

Vorheriges Thema - Nächstes Thema

Samsi

Ja, klappte fast auf Anhieb obwohl ich schepp gebohrt hatte. Ich musste nur am ende die eine Befestigungsschraube korrigieren.

Die lassen sich auch sehr gut löten. 
FHEM 5.5 / BBB Debian Wheezy

Homematic CFG-LAN

HM-Sec-MDIR / HM-Sec-SD / HM-Sec-WDS / HM-LC-Sw2-FM / HM-Sec-SC / HM-LC-Sw1PBU-FM / HM-SCI-3-FM / HM-Sec-Key / HM-RC-Key3-B / HM-LC-Dim1TPBU-FM /  HM-CC-RT-DN / HM-PBI-4-FM / HM-RC-Key4-2 / HM-ES-PMSw1-Pl / HM-LC-Sw4-WM

jab

Abend,

Aktuell kann man das Gerät nicht OTA rebooten. Das kommt mit dem FHEM Flash Support. Ich kann auch eine Config Taster Kombination für reboot einbauen.


Gruß
Jan

Samsi

Hallo Jan,

ich glaube nicht mehr das es an nicht entprellten Tastern liegt, denn der Funkbefehl wurde gesendet:


Events:
2014-05-10 13:06:58 CUL_HM licht_EG_Flur battery: ok
2014-05-10 13:06:58 CUL_HM licht_EG_Flur licht_EG_Flur_Btn_02 Short (to licht_EG_Flur)
2014-05-10 13:06:58 CUL_HM licht_EG_Flur_Btn_02 Short (to licht_EG_Flur)
2014-05-10 13:06:58 CUL_HM licht_EG_Flur_Btn_02 trigger: Short_46
2014-05-10 13:06:58 CUL_HM licht_EG_Flur_Sw_02 trig_licht_EG_Flur_Btn_02: short
2014-05-10 13:06:58 CUL_HM licht_EG_Flur_Sw_02 trigLast: licht_EG_Flur_Btn_02 :short
2014-05-10 13:06:59 CUL_HM licht_EG_Flur_Sw_02 current: 106
2014-05-10 13:07:00 CUL_HM licht_EG_Flur ResndFail
2014-05-10 13:07:00 CUL_HM licht_EG_Flur CMDs_done_Errors:1
2014-05-10 13:07:00 CUL_HM licht_EG_Flur MISSING ACK


EDIT: Ich habe huete auch ein FHEM update gemacht. Ich muss jetzt immer 2x Drücken damit er schaltet.


EDIT2: Ok, ich muss etwas weiter ausholen:

Er war eben in einem 'Status' das ich immer 2x einschalten dürcken musste und dann 2x ausschalten um wieder auszuschalten. Die messages sind aber immer im Eventmonitor gekommen. Das habe ich bestimmt 10 mal hintereinander probiert ohne das er auch nur einmal schon beim ersten mal eingeschaltet hatte. Ich habe dann den Wechselschalter umgelegt und das licht eingeschaltet und dann konnte ich am Aktor durch einmaliges Drücken ausschalten. Und seitdem reicht auch wieder einamliges drücken zum ein- / ausschalten, auch 10 mal getestet.





FHEM 5.5 / BBB Debian Wheezy

Homematic CFG-LAN

HM-Sec-MDIR / HM-Sec-SD / HM-Sec-WDS / HM-LC-Sw2-FM / HM-Sec-SC / HM-LC-Sw1PBU-FM / HM-SCI-3-FM / HM-Sec-Key / HM-RC-Key3-B / HM-LC-Dim1TPBU-FM /  HM-CC-RT-DN / HM-PBI-4-FM / HM-RC-Key4-2 / HM-ES-PMSw1-Pl / HM-LC-Sw4-WM

peterk_de

Huhu Samsi, hast du mal probiert, den/die Taster mit Sw_01 zu peeren statt mit Sw_02? Das Teste ich gerade...
FHEM auf Ubuntu-VM / 2xNUC Proxmox Cluster
UI: HomeKit, TabletUI, Grafana
IOdevs: 2xHueBridge, RaspiMatic-CCU, CUL868, 2xHarmonyHub, 6xRaspi-Roomnode mit CO2, VOC und lepresenced
Devices: 107xHomematic(IP), 96xPhilips Hue, 17xTECHEM, 12xBTLE, 8xSONOS, 2xHomeConnect, 1xShelly 3em, 1xNanoleaf ...

Samsi

Ja, ich hatte ihr zuerst mit Sw_01 gepaart. Das funktionierte aber nicht in der Wechselschaltung. Weil wenn Du auf SW01 Peerst  und dann SW01 einschaltest ist SW01 an, schaltest Du SW_02 nun über die Wechelschaltung aus, ist Sw_01 immer noch an, der Verbraucher  ist aber aus. Einschalten von SW_01 bringt dann aber nichts, weil Sw_01 ja noch an ist.
FHEM 5.5 / BBB Debian Wheezy

Homematic CFG-LAN

HM-Sec-MDIR / HM-Sec-SD / HM-Sec-WDS / HM-LC-Sw2-FM / HM-Sec-SC / HM-LC-Sw1PBU-FM / HM-SCI-3-FM / HM-Sec-Key / HM-RC-Key3-B / HM-LC-Dim1TPBU-FM /  HM-CC-RT-DN / HM-PBI-4-FM / HM-RC-Key4-2 / HM-ES-PMSw1-Pl / HM-LC-Sw4-WM

Samsi

Hallo Jan,

möglicherweise gibt es noch ein Problem mit direkten Perrs. Ich habe einen Aktor (licht_EG_Kueche) mit Custom_FW gepeert mit einen Unterputz Schaltaktor (licht_EG_Couch).

Ich habe den shAction auf off gestellt, damit er nur auf den langen Tastendruck reagiert und toggelt (Einmal Lang Drücken einschalten, noch mal lang drücken Ausschalten). Das Problem ist, sobald die 'wiederholung' beim Langen Tastendruck kommt, schaltet er wider aus.  Wenn ich also lang gedrückt halte, geht es immer abwechselnd an und aus usw.

Nachdem ich Stundenlage die etliche Register verändert habe, habe ich einen HM-Handsender button gepeert und da klappte es auch sofort. Mit den Gleichen Registerwerten geht es mit der Custom-FW nicht.
FHEM 5.5 / BBB Debian Wheezy

Homematic CFG-LAN

HM-Sec-MDIR / HM-Sec-SD / HM-Sec-WDS / HM-LC-Sw2-FM / HM-Sec-SC / HM-LC-Sw1PBU-FM / HM-SCI-3-FM / HM-Sec-Key / HM-RC-Key3-B / HM-LC-Dim1TPBU-FM /  HM-CC-RT-DN / HM-PBI-4-FM / HM-RC-Key4-2 / HM-ES-PMSw1-Pl / HM-LC-Sw4-WM

jab

Hi Samsi,

Das kann ich leider auch reproduzieren. Steht auf der Liste der zu fixenden Dinge.


Gruß
Jan

Samsi

Hallo, Jan,

"Das kann ich leider auch reproduzieren"

Dann bin ich ja beruhigt. Ich war schon am Verzweifeln ;)

FHEM 5.5 / BBB Debian Wheezy

Homematic CFG-LAN

HM-Sec-MDIR / HM-Sec-SD / HM-Sec-WDS / HM-LC-Sw2-FM / HM-Sec-SC / HM-LC-Sw1PBU-FM / HM-SCI-3-FM / HM-Sec-Key / HM-RC-Key3-B / HM-LC-Dim1TPBU-FM /  HM-CC-RT-DN / HM-PBI-4-FM / HM-RC-Key4-2 / HM-ES-PMSw1-Pl / HM-LC-Sw4-WM

frank

hallo jan,

ich möchte den fhem gesteuerten reboot benutzen, aber der tut es nicht so wie erwartet.
martin eröffnet den fwupdate process mit dieser msg:
2014.05.13 17:58:19.404 4: CUL_send:  cul868As 0A 0A 3011 123ABC ABCDEF CA

deswegen habe ich erstmal die reboot if-anweisung folgendermassen geändert:
if((recv.forUs) && (recv.data[2] == 0x30) && (recv_msgTp == 0x11)) {
recv_UpdateEvent();
}

durch starten des fwupdates von fhem passiert nun aber folgendes. die led am schalter fängt dauerhaft zu flackern an. als würde nicht nur ein reboot erzeugt werden, sondern permanent. erst durch ausschalten der versorgungsspannung hört es wieder auf. kann es sein das der watchdog timer durch einmaliges enable dauerhaft aktiv bleibt, obwohl rebootet wird? was kann ich tun? fällt dir noch was schlaues ein?

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

frank

ich glaube das ist schon die lösung. siehe http://www.nongnu.org/avr-libc/user-manual/group__avr__watchdog.html. hier noch was für watchdog freaks: http://www.atmel.com/Images/doc2551.pdf

Zitat
<avr/wdt.h>: Watchdog timer handling
Defines
#define    wdt_reset()   __asm__ __volatile__ ("wdr")
#define    wdt_enable(value)
#define    wdt_disable()
#define    WDTO_15MS   0
#define    WDTO_30MS   1
#define    WDTO_60MS   2
#define    WDTO_120MS   3
#define    WDTO_250MS   4
#define    WDTO_500MS   5
#define    WDTO_1S   6
#define    WDTO_2S   7
#define    WDTO_4S   8
#define    WDTO_8S   9
Detailed Description

#include <avr/wdt.h>

This header file declares the interface to some inline macros handling the watchdog timer present in many AVR devices. In order to prevent the watchdog timer configuration from being accidentally altered by a crashing application, a special timed sequence is required in order to change it. The macros within this header file handle the required sequence automatically before changing any value. Interrupts will be disabled during the manipulation.

Note:
    Depending on the fuse configuration of the particular device, further restrictions might apply, in particular it might be disallowed to turn off the watchdog timer.

Note that for newer devices (ATmega88 and newer, effectively any AVR that has the option to also generate interrupts), the watchdog timer remains active even after a system reset (except a power-on condition), using the fastest prescaler value (approximately 15 ms). It is therefore required to turn off the watchdog early during program startup, the datasheet recommends a sequence like the following:

    #include <stdint.h>
    #include <avr/wdt.h>

    uint8_t mcusr_mirror __attribute__ ((section (".noinit")));

    void get_mcusr(void) \
      __attribute__((naked)) \
      __attribute__((section(".init3")));
    void get_mcusr(void)
    {
      mcusr_mirror = MCUSR;
      MCUSR = 0;
      wdt_disable();
    }

Saving the value of MCUSR in mcusr_mirror is only needed if the application later wants to examine the reset source, but in particular, clearing the watchdog reset flag before disabling the watchdog is required, according to the datasheet.

aber der code ist mir zu kryptisch, als dass ich ihn jetzt irgendwo einfügen würde.

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

jab

Abend,

Wie gesagt das war blind programmiert. Eigentlich sollte beim Reset auch der watchdog zurück gesetzt werden. Bin noch bis morgen in England. Kann es also frühestens Donnerstag testen. Deine Änderungen machen Sinn. Comitte ich gerne ins git. Du kannst aber auch einen Pull Request stellen wenn du willst.


Gruß
Jan

frank

hallo jan,

wenn du demnächst am bootloader schraubst, kannst du dann eventuell gleich einbauen, dass bei erfolgreichem download eine device info message gesendet wird. also die, die gesendet wird, wenn man in den anlernmodus schaltet. damit würde fhem die neue firmwareversion aktualisieren und wohl auch die seriennummer.
mit dem git muss ich mich erst anfreunden.  ;)
vielleicht wäre auch ein kleiner zähler sinnvoll, der die flash versuche zählt. unendlich viele sollten es ja wohl nicht sein.  :)

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

Samsi

Hallo Jan,

ich glaube es gibt auch noch einen Bug (vielleicht auch in der Asksin Lib), heute habe ich festgestellt, das einer meiner Schalter (der erste den ich eingebaut hatte) plötzlich missingAcks hat.

Aus irgend einem Grund wurde das Pairing mit der Zentrale geändert, aus BDCF34 wurde plötzlich BD0034

2014-05-10_22:24:52 licht_EG_Flur_Sw_02 level: 0 %
2014-05-10_22:24:52 licht_EG_Flur_Sw_02 pct: 0
2014-05-10_22:24:52 licht_EG_Flur_Sw_02 deviceMsg: off (to HMLAN1)
2014-05-10_22:24:52 licht_EG_Flur_Sw_02 off
2014-05-10_22:24:52 licht_EG_Flur_Sw_02 timedOn: off
2014-05-10_22:24:52 licht_EG_Flur_Sw_02 level: 0 %
2014-05-10_22:24:52 licht_EG_Flur_Sw_02 pct: 0
2014-05-10_22:24:52 licht_EG_Flur_Sw_02 deviceMsg: off (to licht_EG_Flur)
2014-05-10_22:24:52 licht_EG_Flur_Sw_02 off
2014-05-10_22:24:52 licht_EG_Flur_Sw_02 timedOn: off
2014-05-10_22:24:53 licht_EG_Flur_Sw_02 level: 0 %
2014-05-10_22:24:53 licht_EG_Flur_Sw_02 pct: 0
2014-05-10_22:24:53 licht_EG_Flur_Sw_02 deviceMsg: off (to licht_EG_Flur)
2014-05-10_22:24:53 licht_EG_Flur_Sw_02 off
2014-05-10_22:24:53 licht_EG_Flur_Sw_02 timedOn: off
2014-05-10_22:25:07 licht_EG_Flur_Sw_02 current: 33
2014-05-10_22:25:26 licht_EG_Flur_Sw_02 current: 0
2014-05-10_22:25:45 licht_EG_Flur_Sw_02 current: 0
2014-05-10_22:26:04 licht_EG_Flur_Sw_02 current: 0
Ab hier kommen nur noch regelmässig die Current werte bis zum nächsten Tag
.
.
.
.

2014-05-11_20:09:53 licht_EG_Flur_Sw_02 current: 0
2014-05-11_20:10:12 licht_EG_Flur_Sw_02 current: 0
2014-05-11_20:10:31 licht_EG_Flur_Sw_02 current: 0
2014-05-11_20:11:03 licht_EG_Flur_Sw_02 level: 0 %
2014-05-11_20:11:03 licht_EG_Flur_Sw_02 pct: 0
2014-05-11_20:11:03 licht_EG_Flur_Sw_02 deviceMsg: off (to licht_EG_Flur)
2014-05-11_20:11:03 licht_EG_Flur_Sw_02 off
2014-05-11_20:11:03 licht_EG_Flur_Sw_02 timedOn: off
2014-05-11_20:11:05 licht_EG_Flur_Sw_02 level: 100 %
2014-05-11_20:11:05 licht_EG_Flur_Sw_02 pct: 100
2014-05-11_20:11:05 licht_EG_Flur_Sw_02 deviceMsg: on (to BD0034)
2014-05-11_20:11:05 licht_EG_Flur_Sw_02 on


Ich vermute mal, das ich irgendwas konfiguriert hatte wie aus einem anderen Log am nächsten Tag hervorgeht:

2014-05-10_22:32:01 licht_EG_Flur CMDs_pending
2014-05-10_22:32:02 licht_EG_Flur CMDs_pending
2014-05-10_22:32:02 licht_EG_Flur CMDs_pending
2014-05-10_22:32:03 licht_EG_Flur CMDs_done
2014-05-11_10:30:27 licht_EG_Flur CMDs_pending
2014-05-11_10:30:27 licht_EG_Flur CMDs_pending
2014-05-11_10:31:01 licht_EG_Flur ResndFail
2014-05-11_10:31:01 licht_EG_Flur CMDs_done_Errors:1
2014-05-11_10:31:02 licht_EG_Flur MISSING ACK


Allerdings ganz sicher keine Zentrale BD0034.

Ich wollte das nur mal mitteilen, falls Du (oder jemand anderes) zufällig mal über etwas stolperst. Die anderen Aktoren scheinen bisher normal zu sein.
Ich habe jetzt versucht den Aktor erneut zu pairen damit er die ID der Zentrale überschreibt, aber das klappt scheinbar nicht. Es sieht zwar so aus, als würde er nach einem LongPress mit der ZEntrale kommunizieren wollen es stehen dann auch 2 CMDs pending in der queue, aber es klappt dann nicht (vielleicht weil er nur noch mit BD0034 kommuniziert?).



FHEM 5.5 / BBB Debian Wheezy

Homematic CFG-LAN

HM-Sec-MDIR / HM-Sec-SD / HM-Sec-WDS / HM-LC-Sw2-FM / HM-Sec-SC / HM-LC-Sw1PBU-FM / HM-SCI-3-FM / HM-Sec-Key / HM-RC-Key3-B / HM-LC-Dim1TPBU-FM /  HM-CC-RT-DN / HM-PBI-4-FM / HM-RC-Key4-2 / HM-ES-PMSw1-Pl / HM-LC-Sw4-WM

jab

Hi Frank,

Die todo wird länger aber kann ich machen. Du hast ca 10000 versuche also lohnt ein Counter nicht.

@Samsi: sieht komisch aus. Ich wollte eh noch unit Tests schreiben. Vielleicht finde ich was.

Gruß
Jan

nephdrasil

Hallo ich habe mal eine wahrscheinlich blöde frage,

aber wie bekomme ich die den alternative Firmware auf das Gerät. Ich habe den Bootloader auf dem Gerät installiert und er blinkt am raspberry vor sich hin. Wenn ich per dem Windows tool versuche die Firmeware zu aktualisieren bleibt er bei der Medlung warte auf device stehen.

Was muss ich den dann machen bzw. wie stelle ich fest ob der OTA-Bootloader läuft?

Oder ob ich die Firmeware schon drauf habe?


Kann ich die HMID frei wählen oder muss die mit dem HMCFGUSB übereinstimmen.

Sorry sind doch mehrer fragen.
FHEM 5.5 + Fritz Box 7390 + HM-CFG-USB + HM-CC-RT-DN