Kommunkation mit IO Devices

[Talkabout]

Hallo zusammen,

nachdem es aktuell bei mir ein ziemliches Problem it der Reihenfolge der Stackable CCs (SCCs) gibt, Beschreibung hier:

http://forum.fhem.de/index.php/topic,44796.0.html

versuche ich gerade das 10_IT-Modul anzupassen, damit das funktioniert. Nach stundenlangem Debuggen im Code konnte ich zumindest teilweise Erfolge verzeichnen, allerdings fehlt mir das Insider-Wissen auf welche Art und Weise man mit IO Devices kommuniziert. Vom Rudi habe ich zumindest schonmal die Anhaltspunkte

XXX_Parse
IOWrite

bekommen, allerdings verstehe ich den Zusammenhang noch nicht. Daher wäre es toll wenn mir jemand erklären könnte, wie der genaue Ablauf beim Senden/Empfangen von Nachrichten ist.

Meine erste Frage wäre, wann wird die ParseFn aufgerufen? Ich meine herausgefunden zu haben, dass dies sowohl beim Senden wie auch beim Empfangen passiert, liege ich damit richtig?

Wenn im Frontend das Commando "set XXX on" ausgeführt wird, müsste das Kommando ja im Modul bei XXX_Set landen, korrekt? Heisst das, dass das Senden auf ein IO Device in diesem Fall auch aus der XXX_Set erfolgt?

Wenn ich eine Nachricht abgeschickt habe, bekomme ich die Antwort ja nicht direkt zurück (Stichwort NonBlocking), sondern muss auf diese in der XXX_Read warten, korrekt?

Innerhalb der Methode "IOWrite" wird der Aufruf an die "WriteFn" des Moduls weitergeleitet. Muss diese Methode dann im IT-Modul überschrieben werden? Ich hatte das mal versucht, aber das Skript kam dort nicht rein. Daher vermute ich mal, dass dort in den meisten Fällen nur die "CUL_Write" greift, ist das richtig?

Ich weiss, dass es eine ganze Menge Fragen sind, und vielleicht auch dumme dabei sind. Aber wenn ich mich schon daran mache, das Modul anzupassen, dann möchte ich das nicht wieder falsch machen.

Danke!

Gruss

[rudolfkoenig]

Senden (vereinfacht):

Benutzer: "set Lampe on"
fhem.pl: AnalyzeCommand -> CommandSet -> $modules{FS20}{SetFn}
10_FS20.pm: FS20_Set -> IOWrite -> $modules{$IODev}{WriteFn}
00_CUL.pm: CUL_Write -> $hash->{USBDEV}->write():

Empfang (vereinfacht!)

fhem.pl: globales select -> $modules{$selectlist{XXX}}{ReadFn}
00_CUL.pm: CUL_Read -> Dispatch()
fhem.pl: Dispatch (checkt $modules{CUL}{Clients}) -> $modules{FS20}{ParseFn}
10_FS20.pm: FS20_Parse return "Lampe on" -> DoTrigger("Lampe on")

Falls diese Methode eingehalten wird, dann kann man FHEM2FHEM:RAW verwenden, und auch STACKABLE sollte keine Probleme haben.

Mit dieser Methode ist aus dem logischen Modul heraus kein "get IODev XXX" moeglich, bzw. nur indirekt, indem man auf das Ergebnis spaeter in ParseFn reagiert. In culfw ist aber nicht alles Prefix versehen, so dass z.Bsp. Antwort auf CC1101-Registerabfrage, Version, Hilfe, etc von CUL.pm nicht weitergeleitet wird.

[Talkabout]

Hallo Rudi,

danke für die schnelle Antwort!

Ich denke das reicht erst einmal, um mit dem Umbau zu beginnen. Sollten noch weitere Fragen auftauchen (was wahrscheinlich ist), dann werde ich diese hier posten.

Gruss

[Talkabout]

Hallo Rudi,

mit ein paar geringfügigen Änderungen am Modul bin ich in der Lage alle meine Geräte wieder zu schalten. Ein Problem haben ich aber noch. Wenn Du dir folgende FHEM Log Ausgabe mal anschaust, siehst Du, dass der SCCMAX trotz der Abarbeitung des Befehls durch das IT-Modul den Code bekommt und diesen natürlich nicht interpretieren kann:

Code Auswählen Erweitern

2: IT set WZStehlampeLinks on
2015.11.29 20:06:11 3: simple write: is000F0F000FFF
2015-11-29_20:06:11 EGLicht an
2015-11-29_20:06:11 WZStehlampeLinks an
2015-11-29_20:06:11 WZStehlampen an
2015-11-29_20:06:12 SCCMAX UNKNOWNCODE is000f0f000fff
2015.11.29 20:06:12 3: SCCMAX: Unknown code is000f0f000fff, help me!
2015.11.29 20:06:12 3: WZStehlampeLinks an->on
2015-11-29_20:06:12 EGLicht an
2015-11-29_20:06:12 WZStehlampeLinks an
2015-11-29_20:06:12 WZStehlampen an


Die Zeile "simple write..." stammt aus der 00_CUL.pm, habe ich dort in der CUL_SimpleWrite am Ende als Debug Ausgabe hinterlegt. Damit tritt das Problem auf nachdem der Code gesendet wurde. Ich vermute der Grund hierfür ist, dass das IT-Modul den Code zwar im Format "is000f0f000fff" sendet, er aber irgendwo (ich vermute in der Firmware) in die Dezimal-Darstellung umgerechnet wird. Lasse ich mir den Code nämlich in der IT_Parse ausgeben, kommt dieser dort bereits im Format "i05..." an. Das heisst ich sehe erst einmal für mich keine Möglichkeit diese Fehlermeldung zu unterdrücken, fällt Dir was ein?

Danke!

Gruss

[Talkabout]

Hallo Rudi,

ich habe weitere Details zu dem vorhergehenden Post. Und zwar ist es so, dass wohl die Dispatch-Methode in der fhem.pl aufgerufen wird. Im Hash ist dann "SCCMAX" enthalten, warum er nur die Module CUL_MAX und STACKABLE_CC ausprobiert, die ja beide nichts mit den Codes anfangen können. Kann es sein, dass dort SCCMAX enthalten ist, weil es das Device ganz unten ist?

Gruss

[rudolfkoenig]

Ich verstehe die letzten beiden Beitraege nicht.

1. Beim Schreiben duerfte nur ein Modul betroffen sein (ich braeuchte hier ein log auf "global verbose 5").
2. Beim Empfang einer Nachricht werden alle geladenen "Clients"-Module der IODev gefragt: dessen Match muss zutreffen. Wenn die ParseFn undef zurueckliefert, dann wird weitergesucht. Reihenfolge ist det zweistellige Praefix im Modulnamen. Wenn kein Modul sich zustaendig fuehlt, dann geht es weiter mit IODev->MatchList.
3. Ich kann in SCCMAX nicht nachschauen (keine Ahnung, wo das Modul zu finden ist und wozu es gut ist), und ich muesste die Definitionen deines Testaufbaus kennen, um mitreden zu koennen.

[Talkabout]

Ich verstehe die letzten beiden Beitraege nicht.

1. Beim Schreiben duerfte nur ein Modul betroffen sein (ich braeuchte hier ein log auf "global verbose 5").
2. Beim Empfang einer Nachricht werden alle geladenen "Clients"-Module der IODev gefragt: dessen Match muss zutreffen. Wenn die ParseFn undef zurueckliefert, dann wird weitergesucht. Reihenfolge ist det zweistellige Praefix im Modulnamen. Wenn kein Modul sich zustaendig fuehlt, dann geht es weiter mit IODev->MatchList.
3. Ich kann in SCCMAX nicht nachschauen (keine Ahnung, wo das Modul zu finden ist und wozu es gut ist), und ich muesste die Definitionen deines Testaufbaus kennen, um mitreden zu koennen.

Ich werde Dir das Log mit Verbose 5 heute Abend zukommen lassen.

Der "SCCMAX" ist das physikalische Device für die "MAX"-Frequenz (also der Stackable CC), welcher jetzt ganz unten liegt.

Gruss

[Talkabout]

Hallo Rudi,

hier der Schalt-Vorgang mit Verbose-Level 5:

Code Auswählen Erweitern

2015.11.30 18:44:09 4: FHEMWEB:192.168.20.50:49551 POST /fhem?cmd.WZStehlampeLinks=set%20WZStehlampeLinks%20aus&room=Wohnzimmer&XHR=1&fw_id=undefined; BUFLEN:0
2015.11.30 18:44:09 5: Cmd: >set WZStehlampeLinks aus<
2015.11.30 18:44:09 3: start IT_Set:
2015.11.30 18:44:09 2: IT set WZStehlampeLinks off
2015.11.30 18:44:09 5: SCCMAX sending is000F0F000FF0
2015.11.30 18:44:09 5: SW: is000F0F000FF0
2015.11.30 18:44:10 3: end IT_Set:
2015.11.30 18:44:10 5: Triggering WZStehlampeLinks (1 changes)
2015.11.30 18:44:10 5: Notify loop for WZStehlampeLinks aus
2015.11.30 18:44:10 5: Update structure 'EGLicht' to off because device WZStehlampeLinks has changed
2015.11.30 18:44:10 5: Triggering EGLicht (1 changes)
2015.11.30 18:44:10 5: Notify loop for EGLicht aus
2015.11.30 18:44:10 5: Notify from Device: EGLicht recieved
2015-11-30_18:44:10 EGLicht aus
2015.11.30 18:44:10 5: Notify from Device: WZStehlampeLinks recieved
2015-11-30_18:44:10 WZStehlampeLinks aus
2015.11.30 18:44:10 5: Update structure 'WZStehlampen' to off because device WZStehlampeLinks has changed
2015.11.30 18:44:10 5: Triggering WZStehlampen (1 changes)
2015.11.30 18:44:10 5: Notify loop for WZStehlampen aus
2015.11.30 18:44:10 5: Notify from Device: WZStehlampen recieved
2015-11-30_18:44:10 WZStehlampen aus
2015.11.30 18:44:10 3: start IT_Set:
2015.11.30 18:44:10 3: start IT_Set:
2015.11.30 18:44:10 4: name: /fhem?cmd.WZStehlampeLinks=set%20WZStehlampeLinks%20aus&room=Wohnzimmer&XHR=1&fw_id=undefined / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2015.11.30 18:44:10 4: FHEMWEB:192.168.20.55:35658 GET /fhem/images/default/off.png; BUFLEN:0
2015.11.30 18:44:10 4: FHEMWEB:192.168.20.55:35658 => 304 Not Modified
2015.11.30 18:44:10 5: CUL/RAW: /is000F0F
2015.11.30 18:44:10 5: CUL/RAW: is000F0F/000FF0

2015.11.30 18:44:10 4: CUL_Parse: SCCMAX is000F0F000FF0
2015.11.30 18:44:10 5: Triggering SCCMAX (1 changes)
2015.11.30 18:44:10 5: Notify loop for SCCMAX UNKNOWNCODE is000f0f000ff0
2015.11.30 18:44:10 5: Notify from Device: SCCMAX recieved
2015-11-30_18:44:10 SCCMAX UNKNOWNCODE is000f0f000ff0
2015.11.30 18:44:10 3: SCCMAX: Unknown code is000f0f000ff0, help me!
2015.11.30 18:44:10 5: CUL/RAW: /*i01101454

2015.11.30 18:44:10 4: CUL_Parse: SCCIT i01101454 -32
2015.11.30 18:44:10 3: start IT_Parse: i011014
2015.11.30 18:44:10 4: message "i011014" (7)
2015.11.30 18:44:10 3: WZStehlampeLinks aus->off
2015.11.30 18:44:10 3: end IT_Parse
2015.11.30 18:44:10 5: Triggering WZStehlampeLinks (1 changes)
2015.11.30 18:44:10 5: Notify loop for WZStehlampeLinks aus
2015.11.30 18:44:10 5: Update structure 'EGLicht' to off because device WZStehlampeLinks has changed
2015.11.30 18:44:10 5: Triggering EGLicht (1 changes)
2015.11.30 18:44:10 5: Notify loop for EGLicht aus
2015.11.30 18:44:10 5: Notify from Device: EGLicht recieved
2015-11-30_18:44:10 EGLicht aus
2015.11.30 18:44:10 5: Notify from Device: WZStehlampeLinks recieved
2015-11-30_18:44:10 WZStehlampeLinks aus
2015.11.30 18:44:10 5: Update structure 'WZStehlampen' to off because device WZStehlampeLinks has changed
2015.11.30 18:44:10 5: Triggering WZStehlampen (1 changes)
2015.11.30 18:44:10 5: Notify loop for WZStehlampen aus
2015.11.30 18:44:10 5: Notify from Device: WZStehlampen recieved
2015-11-30_18:44:10 WZStehlampen aus
2015.11.30 18:44:10 3: start IT_Set:
2015.11.30 18:44:10 3: start IT_Set:
2015.11.30 18:44:10 4: FHEMWEB:192.168.20.55:35658 GET /fhem/images/default/off.png; BUFLEN:0
2015.11.30 18:44:10 4: FHEMWEB:192.168.20.55:35658 => 304 Not Modified

WZStehlampeLiinks => die eigentliche Lampe
WZStehlampen => Structure mit WZStehlampeLinks,WZStehlampeRechts
EGLicht => Structure mit allen Lampen im Erdgeschoss (auch WZStehlampen)
SCCMAX => physikalisches Device mit rfmode MAX (liegt als unterster SCC am PI)
SCCIT => physikalsiches Device mit rfmode SlowRf (433 SCC, das die Lampe schaltet, liegt auf dem SCCMAX am PI)

Ich habe noch Debug-Ausgaben in die IT_Set und IT_Parse eingebaut (start, end) damit man sieht, wann diese aufgerufen werden.

Hier die Definitionen der einzelnen Devices:

SCCIT

Code Auswählen Erweitern

define SCCIT STACKABLE_CC SCCMAX
attr SCCIT group CUL
attr SCCIT rfmode SlowRf
attr SCCIT room Server

SCCMAX

Code Auswählen Erweitern

define SCCMAX CUL /dev/ttyAMA0@38400 1234
attr SCCMAX group CUL
attr SCCMAX rfmode MAX
attr SCCMAX room Server

WZStehlampeLinks

Code Auswählen Erweitern

define WZStehlampeLinks IT 000F0F000F FF F0
attr WZStehlampeLinks userattr room_map structexclude
attr WZStehlampeLinks IODev SCCIT
attr WZStehlampeLinks alias Linke Stehlampe
attr WZStehlampeLinks eventMap on:an off:aus
attr WZStehlampeLinks fp_Erdgeschoss 35,635,5,
attr WZStehlampeLinks group Licht Wohnzimmer
attr WZStehlampeLinks model itswitch
attr WZStehlampeLinks room Wohnzimmer
attr WZStehlampeLinks structexclude fp_Erdgeschoss
attr WZStehlampeLinks webCmd an:aus

WZStehlampen

Code Auswählen Erweitern

define WZStehlampen structure room WZStehlampeRechts WZStehlampeLinks
attr WZStehlampen alias Stehlampen
attr WZStehlampen clientstate_behavior last
attr WZStehlampen eventMap on:an off:aus
attr WZStehlampen fp_Erdgeschoss 36,442,5,,
attr WZStehlampen group Licht Wohnzimmer
attr WZStehlampen room Wohnzimmer
attr WZStehlampen webCmd an:aus

EGLicht

Code Auswählen Erweitern

define EGLicht structure room WZStehlampeRechts WZStehlampeLinks WZLicht WZLED EZLicht KULicht EFLicht WCLicht HRLicht DILicht
attr EGLicht alias Licht Erdgeschoss
attr EGLicht clientstate_behavior last
attr EGLicht eventMap on:an off:aus
attr EGLicht room hidden
attr EGLicht structexclude fp_Erdgeschoss

Falls noch Informationen fehlen bitte bescheid sagen.

Danke!

Gruss

[rudolfkoenig]

Vorab etwas Theorie: Das FHEM SCC Modul macht nichts anderes, als vor jedem Befehl ein * zu schreiben, und diese Daten an das drunterliegende IODev zu schicken, bzw. falls der Input mit * anfaengt, die Daten an die naechste Ebene ohne den ersten * weiterreichen.

2015.11.30 18:44:09 2: IT set WZStehlampeLinks off
2015.11.30 18:44:09 5: SCCMAX sending is000F0F000FF0
2015.11.30 18:44:09 5: SW: is000F0F000FF0

-> Da dein SCC fuer IT nicht ganz unten liegt, waere "SW: *is000F0F000FF0" korrekt.

Mit meinem trivialen Config:

Code Auswählen Erweitern

define CUL CUL none 0000
attr CUL verbose 5
attr CUL rfmode MAX

define SCC_1 STACKABLE_CC CUL
attr SCC_1 rfmode SlowRF

define WZStehlampeLinks IT 000F0F000F FF F0


bekomme ich das, was ich erwarte:

2015.12.01 09:23:29.535 2: IT set WZStehlampeLinks on
2015.12.01 09:23:29.535 5: SW: *is000F0F000FFF

Kannst du bitte dein Config diesbezueglich pruefen?

[Talkabout]

Danke Rudi für die Analyse, ich werde heute Abend etwas mit der Config rumspielen.

Gruss

[Talkabout]

Eine Frage kam gestern bei mir noch auf:

Ich kommuniziere jetzt mit dem IO Device über "IOWrite", was auch funktioniert. Ich habe aber festgestellt, wenn ich mehrere Befehle kurz hintereinander abschicke, dass manche verschluckt werden. Wie würde man ein solches Problem Modul-spezifisch lösen, mit einer SendQueue? Oder gibt es im FHEM Core bereits Methoden, die sicherstellen, dass Messages in zu kurzen Abständen nicht gesendet werden? Ich könnte theoretisch einfach ein "sleep" nach dem Senden ausführen, das ist aber meiner Ansicht nach ein Hack der zusätzlich dazu führt, dass FHEM hängen bleibt.

Danke!

Gruss

[rudolfkoenig]

Ich kann dein Problem nicht erklaeren, es duerfte laut Theorie (s.u) gar nicht auftreten.

Mehrere Funktelegramme stoerungsfrei senden ist in FHEM nicht wirklich geloest, es gibt aber Ansaetze:
- Nachrichten, die an das CUL gesendet werden, werden jeweils 0.3s (0.15s fuer HM) verzoegert, siehe CUL_AddSendQueue/CUL_SendFromQueue
- Mehrere CULs koennen per Attribut in einem sendpool landen, damit sie sich nicht gegenseitig stoeren. Da alle SCCs ueber denselben CUL angesprochen werden, ist in deinem Fall sendpool irrelevant, und du muesstest "fein raus" sein.

Was vergleichbares fuer unterschiedliche IODev Typen gibts nicht, man kann sowas hoechstens ueber structure und async_delay als Benutzer zusammenbasteln.

Eine korrekte Loesung ist schwierig, und muesste folgende Daten haben: die Liste an IODevs, die sich gegenseitig stoeren koennen, und wie lange man nach dem Senden mit dem naechsten Auftrag warten soll, das ist manchmal je Nachricht unterschiedlch. Acks von den Gegenstellen (wie bei FHT/MAX/HM) verkomplizieren die Sache zusaetzlich.

[Talkabout]

Vorab etwas Theorie: Das FHEM SCC Modul macht nichts anderes, als vor jedem Befehl ein * zu schreiben, und diese Daten an das drunterliegende IODev zu schicken, bzw. falls der Input mit * anfaengt, die Daten an die naechste Ebene ohne den ersten * weiterreichen.
-> Da dein SCC fuer IT nicht ganz unten liegt, waere "SW: *is000F0F000FF0" korrekt.

Mit meinem trivialen Config:

Code Auswählen Erweitern

define CUL CUL none 0000
attr CUL verbose 5
attr CUL rfmode MAX

define SCC_1 STACKABLE_CC CUL
attr SCC_1 rfmode SlowRF

define WZStehlampeLinks IT 000F0F000F FF F0


bekomme ich das, was ich erwarte:
Kannst du bitte dein Config diesbezueglich pruefen?

Hallo Rudi,

natürlich muss es bei Dir funktionieren, da Du die Änderungen nicht hast, die ich in der 10_IT.pm durchgeführt habe. Im Anhang die modifizierte Version, kannst Du es damit noch mal probieren?

Danke!

Gruss

[rudolfkoenig]

Mit Deiner Version und verbose 5 bekomme ich:

Code Auswählen Erweitern

2015.12.03 16:28:54.798 5: Cmd: >set WZStehlampeLinks on<
2015.12.03 16:28:54.798 2: IT set WZStehlampeLinks on
2015.12.03 16:28:54.798 5: Triggering WZStehlampeLinks (1 changes)
2015.12.03 16:28:54.798 5: Notify loop for WZStehlampeLinks on



Mit dem Original:

Code Auswählen Erweitern

2015.12.03 16:29:27.941 5: Cmd: >set WZStehlampeLinks on<
2015.12.03 16:29:27.941 2: IT set WZStehlampeLinks on
2015.12.03 16:29:27.941 5: SW: *is000F0F000FFF
2015.12.03 16:29:27.952 2: IT IODev device didn't answer is command correctly:   raw => No answer
2015.12.03 16:29:27.952 5: Triggering WZStehlampeLinks (1 changes)
2015.12.03 16:29:27.952 5: Notify loop for WZStehlampeLinks on


Ich ziehe das Original vor, der schaltet vermutlich das Geraet

[Talkabout]

Mit Deiner Version und verbose 5 bekomme ich:

Code Auswählen Erweitern

2015.12.03 16:28:54.798 5: Cmd: >set WZStehlampeLinks on<
2015.12.03 16:28:54.798 2: IT set WZStehlampeLinks on
2015.12.03 16:28:54.798 5: Triggering WZStehlampeLinks (1 changes)
2015.12.03 16:28:54.798 5: Notify loop for WZStehlampeLinks on



Mit dem Original:

Code Auswählen Erweitern

2015.12.03 16:29:27.941 5: Cmd: >set WZStehlampeLinks on<
2015.12.03 16:29:27.941 2: IT set WZStehlampeLinks on
2015.12.03 16:29:27.941 5: SW: *is000F0F000FFF
2015.12.03 16:29:27.952 2: IT IODev device didn't answer is command correctly:   raw => No answer
2015.12.03 16:29:27.952 5: Triggering WZStehlampeLinks (1 changes)
2015.12.03 16:29:27.952 5: Notify loop for WZStehlampeLinks on


Ich ziehe das Original vor, der schaltet vermutlich das Geraet

Hallo Rudi,

ich hatte der Methode "IOWrite" als ersten Parameter das IO-Device statt des Modul-Hashes übergeben, daher die falsche Ausgabe. Jetzt habe ich das geändert und bekomme die folgende Ausgabe:

Code Auswählen Erweitern

2015.12.04 23:06:07 5: Cmd: >set WZStehlampeLinks aus<
2015.12.04 23:06:07 2: IT set WZStehlampeLinks off
2015.12.04 23:06:07 5: SCCMAX sending *is000F0F000FF0
2015.12.04 23:06:07 5: SW: *is000F0F000FF0
2015.12.04 23:06:07 5: Triggering WZStehlampeLinks (1 changes)
2015.12.04 23:06:07 5: Notify loop for WZStehlampeLinks aus
2015.12.04 23:06:07 5: Update structure 'EGLicht' to off because device WZStehlampeLinks has changed
2015.12.04 23:06:07 5: Triggering EGLicht (1 changes)
2015.12.04 23:06:07 5: Notify loop for EGLicht aus
2015.12.04 23:06:07 5: Notify from Device: EGLicht recieved
2015-12-04_23:06:07 EGLicht aus
2015.12.04 23:06:08 5: Notify from Device: WZStehlampeLinks recieved
2015-12-04_23:06:07 WZStehlampeLinks aus
2015.12.04 23:06:08 5: Update structure 'WZStehlampen' to off because device WZStehlampeLinks has changed
2015.12.04 23:06:08 5: Triggering WZStehlampen (1 changes)
2015.12.04 23:06:08 5: Notify loop for WZStehlampen aus
2015.12.04 23:06:08 5: Notify from Device: WZStehlampen recieved
2015-12-04_23:06:08 WZStehlampen aus
2015.12.04 23:06:08 4: name: /fhem?cmd.WZStehlampeLinks=set%20WZStehlampeLinks%20aus&room=Wohnzimmer&XHR=1&fw_id=undefined / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2015.12.04 23:06:08 5: CUL/RAW: /*is000F0
2015.12.04 23:06:08 5: CUL/RAW: *is000F0/F000FF0
/015.12.04 23:06:08 5: CUL/RAW: *is000F0F000FF0

2015.12.04 23:06:08 4: CUL_Parse: SCCIT is000F0F000FF0
2015.12.04 23:06:08 3: message "is000f0f000ff0" (14) too short!
2015.12.04 23:06:08 3: message "is000f0f000ff0" (14) too short!
2015.12.04 23:06:08 5: Triggering SCCIT (1 changes)
2015.12.04 23:06:08 5: Notify loop for SCCIT UNKNOWNCODE is000f0f000ff0
2015.12.04 23:06:08 5: Notify from Device: SCCIT recieved
2015-12-04_23:06:08 SCCIT UNKNOWNCODE is000f0f000ff0
2015.12.04 23:06:08 3: SCCIT: Unknown code is000f0f000ff0, help me!

Das heisst es wird korrekterweise der Message ein "*" voran gestellt, da mein Intertechno SCC sich an 2. Stelle (von unten) befindet. Leider, obwohl die Nachricht korrekt ist, wird die Nachricht nicht abgeschickt. Meiner Ansicht nach befinde ich mich nach dem Statement "SW: *is000F0F000FF0" bereits auf Firmware-Ebene, da dort das physikalische Device angestoßen wird, korrekt?

Kann das Problem also schon in der Firmware für Intertechno liegen? Vielleicht hast Du noch einen anderen Tipp, wo ich ansetzen kann zur Fehleranalyse.

Das fehlerhafte Parsen am Ende kannst Du erst einmal ignorieren, dies sollte keine Auswirkungen auf das Senden haben.

Danke!

Gruss