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

deune

Hallo Michael,

im Anhang ist die angesprochene Fehlermeldung! Ein Kompilieren mit der Hardware Board Einstellung "Jabduino ATMEGA 644"  ohne das "A" geht ohne Fehlermeldung durch.

Allerdings weis ich nicht wo dann das hex-File  liegt und ist ja auch wahrscheinlich nicht lauffähig.

Herzliche Grüße

Holger

mmattern

Zitat von: deune am 24 September 2014, 21:27:38
Hallo Michael,

im Anhang ist die angesprochene Fehlermeldung! Ein Kompilieren mit der Hardware Board Einstellung "Jabduino ATMEGA 644"  ohne das "A" geht ohne Fehlermeldung durch.

Allerdings weis ich nicht wo dann das hex-File  liegt und ist ja auch wahrscheinlich nicht lauffähig.

Herzliche Grüße

Holger

Hallo,

das hex-File sollte lauffähig sein... und es müsste im Log auch stehen, wo das hex-File landet... war bei mir immer ein temporäres Verzeichnis mit sehr langem Pfad...

Viele Grüße
Michael
2x Raspberry Pi, 2x HM-CFG-LAN, 2x HM-CFG-USB, 2x HM-ES-PMSw1-Pl, 3x HM-LC-BL1-FM, 10x HM-LC-Bl1PBU-FM, 6x HM-LC-Sw1PBU-FM-CustomFW, 2x HM-PB-2-WM55-2, 4x HM-PB-6-WM55, 2x HM-SEC-MDIR-2, 6x HM-SEC-RHS, 2x HM-SEC-WIN, 2x HM-Sys-sRP-Pl

jab

Morgen,

Zwischen Atmel644 und Atmel644A gibt es praktisch keinen Unterschied. Es geht mit beiden. Man kann in den Settings der Arduino IDE einstellen, dass er den Pfad des Binaries anzeigt.


Gruß
Jan

Mr. P

Zitat von: Brocken am 24 September 2014, 12:57:18
Werde mich aber sofort melden wenn die Nadeln bei Holger angekommen sind !!!
Hej Gerd,

vielen Dank für deine Antwort. Prognadeln hab ich leider keine, nein.
Werde mich daher also doch brav gedulden müssen, bis ihr alles beisammen habt und bereit seid. :-)
Greetz,
   Mr. P

Akwak

Hi,
Hat jemand den so modifizierten Schalter in Verbindung mit einer CCU im Einsatz?
Wie stellt er sich dort dar?
Gruss
Alfred

cactus-online

Nein. Dazu muss erst das Device bekannt gemacht werden, so wie Uwe das für seinen Universalsensor exemplarisch vorgemacht hat.

jab

Moin,

ich habe in den letzten Tagen das einmal mit der CCU2 versucht. Ein XML zu bauen ist nicht so schwer. Leider ist die CCU ziemlich begrenzt in ihren Möglichkeiten. Konkret gibt es Probleme, wenn ein Gerät nicht klar zu einem Subtype gehört (Schalter, Fernbedienung etc). Möglicherweise geht es irgendwie aber ich habe es nicht hinbekommen. Z.b. wenn man ein Gerät mit Subtype 0x10 hat (Schalter) dann ignoriert die CCU2 alle Taster Channel. Umgekehrt ignoriert sie die Schalter Channel wenn ich das Gerät als Subtype Remote implementiere. Zusätzlich gibt es einen Internal Error wenn man Geräte peeren will, falls irgendein Channel aus der XML ignoriert wurde (bzw als ein andere Typ angezeigt wird). Falls mir jemand sagen kann wie man unterschiedliche Channel für ein Gerät hinbekommt wäre ich über jeden Hinweis dankbar.


Gruß,
Jan

Dirk

Zitat von: jab am 27 September 2014, 22:38:23
Konkret gibt es Probleme, wenn ein Gerät nicht klar zu einem Subtype gehört (Schalter, Fernbedienung etc). Möglicherweise geht es irgendwie aber ich habe es nicht hinbekommen.
Wenn man der CCU neue Gerätetypen beibringen will, dann kommt man um einen Patch nicht herum.
Schau dir mal das CCU-Addon vom Universalsensor an welches ich gebaut habe:
https://github.com/kc-GitHub/Wettersensor/tree/master/Tools/CCU

Gruß
Dirk

jab

Hi Dirk,

Ja genau so habe ich das auch gemacht. Die CCU kommt aber trotzdem nicht damit klar wenn ich in meinem XML zwei Aktor und zwei Remote Channels definiere. Je nachdem welchen Subtype ich im Device schicke (in der Deviceinfo) geht nur der entsprechende Type. Eigene Events (wie current) sind kein Problem. Ich verstehe halt nicht wieso der Subtype überhaupt eine Rolle spielt wenn ich das XML für die Channel habe.


Gruß
Jan

cactus-online

Hmm, möglicherweise ist ja genau das das Problem, warum eQ3 diesen Schalter so kastriert hat. Vielleicht geht das grundsätzlich nicht. Ich will es nicht hoffen, da ich in meiner ganzen Planung davon ausgegangen bin, das die neue Firmware auch an der CCU nutzbar zu machen sein wird  >:(.

PumpkinEater

Hallo zusammen,
ich würde den geflashten Schalter auch gern mit der CCU2 verwenden, um eine Kreuzschaltung vernünftig zu realisieren. Ich benötge in meinem Fall nur den Wechselschalter und die Stromerkennung, auf die Taster könnte ich verzichten. Wäre das mit der alternativen Firmware möglich?

Gruß
Peter


frank

mit fhem und der firmware ist eine wechsel-/kreuzschaltung möglich.

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

Moin Peter,

Ja das geht mit der CCU sogar ohne Patch/neuem XML. Man müsste dafür nur noch die Deviceinfo in der Firmware anpassen. Dann hast du einen Schalter mit zwei Channel. Strommesswert würde er nicht anzeigen aber Channel 2 zeigt ob Strom fließt oder nicht. Der Messwert an sich ist aber eh nicht sehr nützlich.

Anpassen müsste man: Subtype (afaik 0x10) und die paar Bits danach denn da steht drin wie viele Channel das Gerät hat. Außerdem müsste man das F0 im Devicetype durch 00 ersetzen. Das haben wir geändert damit FHEM das Gerät mit meinem Code handelt.

Habe leider keine CCU Zuhause daher müsste das jemand anderes testen.


Gruß
Jan

cactus-online

Das heißt im Umkehrschluss, eine Kopie der Original-XML mit veränderter Device-Info müsste es auch tun ?

jab

Leider nein. Der Subtype und die Bits danach müssen geändert werden. Es gibt eh nur ein XML für alle Schalter zusammen. Die Types werden alle auf einen gemappt. Die Zahl der Channels ließt er dann aus den Bits (steht in der XML aus welchen).


Gruß
Jan