CUL + BURST

[Dirk]

Hallo Zusammen,

ich bin hier grade am Analysieren einiger Probleme im CUL_HM.

Dabei stelle ich fest, das FHEM+CUL nicht mit einem HM-LC-SW1-BA-PCB sprechen möchte.

Bei FHEM+HMLAN funktioniert das ohne Probleme.

Nun, HM-LC-SW1-BA-PCB ist ein Batterie-Aktor und möchte ein BURST zum Aufwachen. Kann es sein, dass 00_CUL.pm oder vielleicht sogar die CUL Firmware das noch gar nicht implementiert hat? CUL_HM sendet richtigerweise ein gesetztes BURST-Bit

14:58:24.797 1: len: 0E nr: 23 cc: B0 typ: 11 s: ABCDEF d: 123456 pl: 0201C80000

Gruß

Dirk

[Rudolf Koenig]

> Kann es sein, dass 00_CUL.pm oder vielleicht sogar die CUL Firmware das noch
> gar nicht implementiert hat? CUL_HM sendet richtigerweise ein gesetztes
> BURST-Bit

Was auch immer burst ist:
- es gibt ein entsprechend genanntes Bit im HM Paket.
- da ich es nicht weiss, was es bedeutet, hat meine Version von CUL_HM es nicht
bewusst gesetzt. Ob Martins Version von CUL_HM das besser macht, weiss ich
nicht.
- culfw reagiert nicht darauf.

Ich haette gerne eine (genaue) Erklaerung, was BURST bedeutet, dann koennte man
es auch implementieren.

[Martin]

Beschrieben ist, dass ein Burst device 'geweckt' werden muss um auf Empfang zu gehen.
Es gibt ein Bit im flagByte das hierfuer zustaendig ist. Es muss in der ersten Message gesetzt werden, folgenden brauchen  es nicht mehr.

In jeden Sender (rc, taster) kann man setzen, ob der "peer" burst braucht. Dan faehrt der Sender den Aufweckmode vor Beginn der Uebertragung.

In CUL_HM sind jetzt alle models mit dem entsprechenden Attribut versehen und das Flag wird automatich eingefuegt.

Burst wird offensichtlich von einigen Battariedevices unterstuetzt die auf basis den Bits im Flag ihren uP 'hochfahren'.

burst ist fuer 00_HMLAN transparent. Ob die HW noch etwas einbaut kann ich nicht sagen

[Felix Storm]

Hallo Martin,

etwas off topic aus persönlichem Interesse:

Beschrieben ist, dass ein Burst device 'geweckt' werden muss um auf Empfang zu gehen.
Es gibt ein Bit im flagByte das hierfuer zustaendig ist. Es muss in der ersten Message gesetzt werden, folgenden brauchen  es nicht mehr.

Hast Du irgendwelche Unterlagen, Links etc., in denen solche Details beschrieben sind? Ich entwickele nebenbei eine HM-Implementierung für AVR ATmega Controller (https://github.com/glueckkanja/AvrHmLibrary) und bin daher an jeder Art von Doku interessiert. Ich habe als Quellen für mich bis jetzt hauptsächlich das alte/neue fhem-HM-Modul, die XML-Files aus den CCU-Firmware-Images, die Debug-Traces des HM-USB-Konfigurationsadapters und langwierige Auswertung von eigenen HM-Dumps verwendet...

Danke und viele Grüße,
Felix

[Martin]

Hallo Felix,

mehr habe ich auch nicht. Wie ich es mache kannst du in code selbst sehen. Viele Infos und das Erstellen der Tabellen habe ich aus den XML extrahiert.
Ist so weitgehend stabil - nur das Interface zum HMLAN ist nicht belastbar. Daran arbeite ich gerade und versuche es zu verstehen. Bin gerade einen Schritt weiter (hoffe ich)...

Frage, gerne - auch per email. Vielleicht  habe ich auch welche ;-)

Gruss
martin

[Felix Storm]

Hallo Martin,

 

sorry für meine späte Antwort und danke für die Info. Du kannst Dich natürlich auch gerne bei mir melden – bei mir läuft das HM-Thema zwar nur nebenher und sporadisch, aber wenn ich eine Idee habe, helfe ich gerne weiter.

 

Viele Grüße,

Felix

--
Sie haben diese Nachricht erhalten, weil Sie der Google Groups-Gruppe FHEM developers beigetreten sind.
Besuchen Sie https://groups.google.com/d/msg/fhem-developers/-/lXTp8Aa6fIIJ, um diese Diskussion im Web anzuzeigen.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-de...@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-develope...@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-developers?hl=de, um weitere Optionen zu erhalten.