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

Pythonf · 25 März 2015, 11:22:59

Bei 644A kommt folgender Fehler:

MCU 'atmega644a' supported for assemler only
und darunter jede Menge "was not declared in this scope" Fehlermeldungen

Bei Arduino 1.6 funktioniert es ja leider garnicht.

Code Auswählen

Arduino: 1.6.0 (Windows 7), Platine: "Jabduino ATmega644"

Die Fremdhersteller-platform.txt definiert keinen compiler.path. Bitte melden Sie dies an den Fremdhersteller.

Fehler beim Übersetzen: Fehlender Konfigurationsparameter 'recipe.cpp.o.pattern'

  Dieser Report hätte mehr Informationen mit
  "Ausführliche Ausgabe während der Kompilierung"
  aktiviert in Datei > Einstellungen

Beste Grüße
Fabian

frank · 25 März 2015, 12:26:45

bei mir funktioniert ide 1.0.5 mit win7.

Pythonf · 25 März 2015, 13:14:24

Mit der 1.0.5 Hat es nun endlich funktioniert.
Vielen Dank.

Pythonf · 25 März 2015, 20:24:07

Ich hab nun den OTA Bootloader auf das Gerät geschrieben, HMID und Seriennummer hatte ich angepasst. AVRDUDE meldet succesfull.
Das ganze wie im Forum beschrieben nur per USB und USPasp an einem Windows Rechner. Dann habe ich die Firmware in Arduino kompiliert (HMID angepasst) und ebenfalls per USBasp aufgespielt. Alles abgelötet und zurück angeschlossen.

Nur leider funktioniert jetzt nichts mehr. Die Grüne Config LED leuchtet garnicht mehr auf. Mit FHEM pairen klappt nicht (die *.pm ist im Verzeichnis).
laut github readme "Version 1: Upload with programmer (works with or without arduino bootloader)" sollte das aufspielen über arduino ja auch mit OTA Bootloader funktionieren.
Ist der Bootloader in einen anderen Speicher geschrieben als die Firmware?
Ich habe leider aktuell keinen HMUSB und keinen CUL zur hand. Lediglich einen HMLAN, aber der hilft ja bei FW-Updates (merkwürdigerweise?) nicht weiter.

Vielleicht ist ja irgendwo ein offensichtlicher Fehler meinerseits?
Ich hoffe, ihr könnt mir irgendwie helfen.

Beste Grüße
Fabian

frank · 25 März 2015, 21:45:55

der hinweis im readme besagt, dass die fw auch ohne existierenden bootloader geflasht werden kann, weil frueher gab es noch keinen bootloader. beides nacheinander geht wohl nicht ohne weiteres. wollte ich frueher auch mal machen. habe aber nie eine loesung gefunden. dirk hat fuer den universalsensor ein flashtool gebaut, dass aus beiden teilen ein flashfile bauen kann. vielleicht kannst du das umbauen und benutzen.

Pythonf · 25 März 2015, 22:27:18

Das werde ich wohl nicht so schnell hinbekommen.
Ich werd mir dann wohl den HMUSB eines Freundes ausleihen und nur den OTA Bootloader 8K flashen. Dann sollte ich die FW ota aufspielen können?
Vielleicht kann man das ja in der readme anpassen, dass wirkt für mich etwas missverständlich ausgedrückt.

Beste Grüße
Fabian

Pelan · 26 März 2015, 09:30:13

Hallo Zusammen,

ich habe insgesamt 2 HM_LC_Sw1PBU mit der alternativen Firmware geflasht. An dieser Stelle noch mal ein herzliches Dankeschön an die Macher!
Bei einem Schalter bekomme ich im 2 Sekundentakt ein CMDs_done im Logfile. Im Fhem-Log findet sich dann immer folgender Eintrag:
(der Schalter heißt "wf_sw1", der Channel 4 ist "wf_sw1_Sw_02")

Code Auswählen


2015.03.26 09:03:39 5: HMLAN_Parse: HMLAN1 R:E261298   stat:0000 t:03AEDCA1 d:FF r:FFA9     m:59 A410 261298 424242 0604000000
2015.03.26 09:03:39 5: HMLAN1 dispatch A0E59A4102612984242420604000000::-87:HMLAN1
2015.03.26 09:03:39 5: HMLAN: Skip ACK
2015.03.26 09:03:39 5: CUL_HM wf_sw1 protEvent:CMDs_done
2015.03.26 09:03:39 5: CUL_HM wf_sw1 sent ACK:2
2015.03.26 09:03:39 5: Triggering wf_sw1 (1 changes)
2015.03.26 09:03:39 5: Notify loop for wf_sw1 CMDs_done
2015.03.26 09:03:39 5: rg_battery: not on any display, ignoring notify
2015.03.26 09:03:39 5: Triggering wf_sw1_Sw_02 (5 changes)
2015.03.26 09:03:39 5: Notify loop for wf_sw1_Sw_02 deviceMsg: off (to HMLAN1)
2015.03.26 09:03:39 5: rg_battery: not on any display, ignoring notify
2015.03.26 09:03:41 5: HMLAN/RAW: /E261298,0000,03AEE4BA,FF,FFA9,5AA4102612984242420604000000

Was kann diese "Notify loop" auslösen? Der Sw_02 wird eigentlich bei mir nicht verwendet, da der Schalter in einer "normel" Ein/Aus Konfiguration arbeitet. Die Stromerkennung verwende ich hier also nicht.

Vielen Dank schon mal im Voraus für eure Unterstützung.
Gruß,
Arndt

Tobias · 26 März 2015, 12:28:47

Zitat von: frank am 20 März 2015, 17:11:02
mit diesen änderungen hat der configtaster in der fw folgende funktionen:
[/u]
1. short
einmal kurz drücken erzeugt einfaches blinken. ist aber weiterhin ohne funktion.

2. long und double long
langes drücken, ab 3 sekunden, erzeugt nun 3-faches blinken. die anlernmessage wird gesendet. zum pairen kann man nun den taster loslassen. wird danach erneut lange gedrückt, wird weiterhin ein reset des schalters ausgelöst. die eepromdaten werden auf werkseinstellungen gesetzt. eigentlich alles wie bisher. ich habe nur eine rückmeldung mit 3-fachem blinken für das erreichen des pairing modus eingebaut. ausserdem ist das lange drücken von 5 sekunden auf nun 3 sekunden verkürzt, um die folgenden funktionen etwas schneller zu erreichen.

3. multi long
der schalter hat nun ein "bootmenü" mit 3 menüoptionen. man gelangt in das menü, indem man das lange drücken des tasters über die ersten 3 sekunden verlängert. jede weiteren 3 sekunden erfolgt ein umschalten in eine weitere bootmenüoption. die augenblickliche option wird durch blinken angezeigt. 1 option 1x blinken, 2.option 2x blinken und 3. option 3x blinken. nach der 3. option gelangt man wieder in die erste option, usw ... wird der taster nach dem jeweiligen blinken losgelassen, wird die entsprechende menüoption ausgeführt. die menüoptionen haben folgende bedeutung (optionen 2 und 3 sind hier noch funktionslos):

option 1: manueller reboot
option 2: enable software reboot (fhem kann durch set fwupdate das booten einleiten)
option 3: disable software reboot (das automatische booten wird verhindert, default)

beispiel1: um ein manuellen reboot des schalters auszuführen, muss man den taster 6 sekunden drücken. nach 3 sekunden erfolgt das 3-fache blinken für den pairingmodus und nach weiteren 3 sekunden erfolgt nun ein 1-faches blinken für das erreichen der ersten option des bootloadermenüs. nach dem blinken loslassen. da das menü zirkuliert erreicht man das manuelle booten auch nach 15 sekunden.

die optionen 2 und 3 sollen einmal zum automatischen update durch fhem dienen. nur wer seinen schalter über das manuelle konfigurieren dieses bootmenüs mit option 2 freigeschaltet hat, ermöglicht fhem ein automatisch gestartetes update über den befehl set fwUpdate. mit option 3 kann es dann wieder ausgeschaltet werden. mit der definition AUTO_BOOT true in register.h könnte man den defaultwert umstellen.

viel spass beim testen.

gruss frank

Sehr einfach gesagt: ES FUNKTIONIERT!

Manchmal erkennt zwar flash-ota nach dem ersten blinken (-> reboot) kein reboot, aber grundsätzlich funktioniert es supi!
Hiermit beantrage ich das die Änderungen ins Repo einfließen....

Fehlt jetzt nur noch das die HMID und Serial aus dem Bootloader gelesen werden könen.....

Pythonf · 26 März 2015, 14:55:40

Ich hab bei meinem Schalter BTN01 mit SW01 per single set gepeert. Des Weiteren wollte ich wollte ich ein Notify auf ein .Long.* setzten um einen LEDController zu dimmen. Leider verschwindet nach dem peeren die Möglichkeit auf BTN01.Long.* zu triggern. Ebfenfalls blinkt das Raumlicht bei langem gedrückt halten. Gibt es Readings die man dies bezüglich anpassen kann oder muss das ganze dann vollständig über ein Notify in FHEM für LED und Raumlicht gelöst werden, was unnötigen Traffic erzeugen würde?

Beste Grüße
Fabian

Tobias · 27 März 2015, 09:36:34

Hi,
bei einer echten Wechselschaltung sieht man ja am "state" des SW_02 den Status des Verbrauchers. Dummerweise gibt es aber kein Event wenn der Status von SW_02 von off nach on wechselt. Kann das bitte noch in das FHEM pm-Modul mit aufgenommen werden?

frank · 27 März 2015, 17:49:55

Zitat von: Tobias am 27 März 2015, 09:36:34
Hi,
bei einer echten Wechselschaltung sieht man ja am "state" des SW_02 den Status des Verbrauchers. Dummerweise gibt es aber kein Event wenn der Status von SW_02 von off nach on wechselt. Kann das bitte noch in das FHEM pm-Modul mit aufgenommen werden?

bei mir schon.

Code Auswählen

17:34:36  SwitchPBU01_Sw_02 current: 338
17:34:34  SwitchPBU01_Sw_02 timedOn: off
17:34:34  SwitchPBU01_Sw_02 on
17:34:34  SwitchPBU01_Sw_02 deviceMsg: on (to ccu)
17:34:34  SwitchPBU01_Sw_02 pct: 100
17:34:34  SwitchPBU01_Sw_02 level: 100 %

hast du den wert der variable für die strommessung richtig dimensioniert?

frank · 27 März 2015, 18:04:25

Zitat von: Pythonf am 26 März 2015, 14:55:40
Ich hab bei meinem Schalter BTN01 mit SW01 per single set gepeert. Des Weiteren wollte ich wollte ich ein Notify auf ein .Long.* setzten um einen LEDController zu dimmen. Leider verschwindet nach dem peeren die Möglichkeit auf BTN01.Long.* zu triggern. Ebfenfalls blinkt das Raumlicht bei langem gedrückt halten. Gibt es Readings die man dies bezüglich anpassen kann oder muss das ganze dann vollständig über ein Notify in FHEM für LED und Raumlicht gelöst werden, was unnötigen Traffic erzeugen würde?

Beste Grüße
Fabian

bei mir kommen long-meldungen.
btn2 habe ich mit sw1 gepeert und toggle den aktor mit short. auf long triggere ich ein notify, das mir gegebenenfalls die rauchmelder bei alarm ausschaltet. zusätzlich habe ich sogar noch einen virtuellen aktor gepeert, aber mir fällt gerade nicht mehr ein, warum?

btn1 habe ich mit einem dimmer gepeert. den schalte ich mit short an/aus und mit long wird gedimmt.

so sieht das notify-def aus

Code Auswählen

SwitchPBU01_Btn_02.*Long.* set SDTeam_Btn1 alarmOff

um das blinken abzuschalten setze folgendes register mal auf off:

Code Auswählen

3: lgActionType | literal | required | options:toggleToCntInv,off,toggleToCnt,jmpToTarget

der2of6 · 27 März 2015, 18:48:46

Ganz anderes Thema:
Gibts einen Bauplan für den Programieradapter der irgendwo in Threadmitte beschrieben ist?

Tobias · 28 März 2015, 07:33:18

Zitat von: Tobias am 27 März 2015, 09:36:34
Hi,
bei einer echten Wechselschaltung sieht man ja am "state" des SW_02 den Status des Verbrauchers. Dummerweise gibt es aber kein Event wenn der Status von SW_02 von off nach on wechselt. Kann das bitte noch in das FHEM pm-Modul mit aufgenommen werden?

@FRank,
zumindest regiert mien Stateformat des Devices nicht auf die Änderung im Channel4

Code Auswählen

attr <Device> stateFormat {ReadingsVal($defs{"$name"}{channel_04}, "state","")}

Pythonf · 29 März 2015, 13:53:40

Ich hab ein Problem, wenn ich auf ein .Long.* eines bereits gepeerten Kanals trigger. Hier ein kurzer Auszug aus dem Event Monitor der relevanten Stellen:

Code Auswählen



2015-03-29 13:48:01 CUL_HM Fabian.Lichtschalter01_Btn_01 trigger: Long_29

2015-03-29 13:48:06 CUL_HM Fabian.Lichtschalter01_Sw_01 deviceMsg: on (to Fabian.Lichtschalter01)
2015-03-29 13:48:06 CUL_HM Fabian.Lichtschalter01_Sw_01 level: 100 %
2015-03-29 13:48:06 CUL_HM Fabian.Lichtschalter01_Sw_01 pct: 100
2015-03-29 13:48:06 CUL_HM Fabian.Lichtschalter01_Sw_01 on
2015-03-29 13:48:06 CUL_HM Fabian.Lichtschalter01_Sw_01 timedOn: running

Es fehlt jedlicher Eintrag von BTN_02 (welcher intern per single set gepeert ist).
Auch ein Regset gegen das Blinken funktioniert nicht:

Code Auswählen

set Fabian.Lichtschalter01_Sw_01 regSet lgActionType off
liefert ein, für mich unerklärliches

Code Auswählen

Peer not specified

Was mich noch interessieren würde. Kann es sein, dass das Interne peeren selten eine Verzögerung oder ein nicht schalten des Raumlichtes verursachen kann (im vgl zur Originial-FW)? Ist bei mir bisher 2x Aufgetreten und nicht reproduzierbar.

Habt ihr eine Idee, was bei mir falsch läuft?
Bei einem peerChan .. dual set wurde auf beiden Tastern kein Long.* mehr gesendet.

Beste Grüße
Fabian