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
Senden (vereinfacht):
ZitatBenutzer: "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!)
Zitatfhem.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.
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
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:
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
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
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.
Zitat von: rudolfkoenig am 30 November 2015, 07:13:41
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
Hallo Rudi,
hier der Schalt-Vorgang mit Verbose-Level 5:
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
define SCCIT STACKABLE_CC SCCMAX
attr SCCIT group CUL
attr SCCIT rfmode SlowRf
attr SCCIT room Server
SCCMAX
define SCCMAX CUL /dev/ttyAMA0@38400 1234
attr SCCMAX group CUL
attr SCCMAX rfmode MAX
attr SCCMAX room Server
WZStehlampeLinks
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
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
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
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.
Zitat2015.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:
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:
Zitat2015.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?
Danke Rudi für die Analyse, ich werde heute Abend etwas mit der Config rumspielen.
Gruss
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
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.
Zitat von: rudolfkoenig am 01 Dezember 2015, 09:30:51
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:
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
Mit Deiner Version und verbose 5 bekomme ich:
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:
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 :)
Zitat von: rudolfkoenig am 03 Dezember 2015, 16:32:14
Mit Deiner Version und verbose 5 bekomme ich:
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:
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:
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
Setzt mal fuer die unterschiedlichen SCCs auch unterschiedliche FHTIDs, und versuch diese abzufragen (get SCC raw T01) oder version, uptime, etc, um zu wissen, ob die Nachrichten korrekt weitergereicht werden.
Man koennte sich mit "screen /dev/ttyAMA0" direkt mit der untersten SCC verbinden, und die Kommandos V, *V, T01, *T01, C99, *C99, t, *t, usw durchprobieren.
Zitat von: rudolfkoenig am 05 Dezember 2015, 13:03:17
Setzt mal fuer die unterschiedlichen SCCs auch unterschiedliche FHTIDs, und versuch diese abzufragen (get SCC raw T01) oder version, uptime, etc, um zu wissen, ob die Nachrichten korrekt weitergereicht werden.
Man koennte sich mit "screen /dev/ttyAMA0" direkt mit der untersten SCC verbinden, und die Kommandos V, *V, T01, *T01, C99, *C99, t, *t, usw durchprobieren.
Hallo Rudi,
die FHTIDs konnte ich nicht setzen, da es diesen Parameter für die STACKABLE_CCs nicht gibt (nur für CUL). Führe ich aber "version" auf allen aus, kommt die korrekt Firmware-Version zurück:
SCCMAX version => V 1.61 CSM868
SCCIT version => V 1.10.02 a-culfw Build: 171 (2015-10-29_21-49-43) CSM433 (F-Band: 433MHz)
SCCHomeMatic version => V 1.60 CSM868
SCC868SlowRf version => V 1.61 CSM868
Demnach scheinen die Nachrichten korrekt weitergeleitet zu werden.
Mir ist diese Logik mit den "*" noch nicht ganz klar. Ich verstehe, dass wenn eine Nachricht an ein SCC gehen soll, für jedes darunter liegende SCC ein weiteres "*" an den Anfang gestellt wird. Aber an welcher Stelle wird diese Logik dann aufgelöst, in der Firmware oder in FHEM? Da sowohl mein SCC für HomeMatic wie SlowRf die Nachrichten korrekt sendet/empfängt, vermute ich ein Problem sowohl bei der MAX-Implementierung wie auch bei Intertechno. Ich weiss halt bloß nicht, ob das Problem in FHEM oder in der Firmware liegt. Vielleicht wird es etwas klarer, wenn ich die Logik mit den "*" verstehe.
Danke!
Gruss
Meine Vermutung ist, dass die Firmware für Intertechno die vorangestellten "*" nicht korrekt auflöst, und deswegen nichts geschaltet wird, wenn der SCC nicht ganz unten liegt (was dazu führen würde, dass keine "*" vorangestellt werden). Um das zu verifizieren müsste ich aber genau wissen, ob diese Auflösung in der Firmware oder doch in FHEM stattfindet.
Gruss
Zitatdie FHTIDs konnte ich nicht setzen, da es diesen Parameter für die STACKABLE_CCs nicht gibt (nur für CUL).
set SCC1 raw T011234
ZitatSCCIT version => V 1.10.02 a-culfw Build: 171 (2015-10-29_21-49-43) CSM433 (F-Band: 433MHz)
Aeh: das hast du bisher verschwiegen, oder ich hatte Tomaten auf den Augen.
Bitte mit Bjoern/etc weiter debuggen, ich bin raus.
Zitatdiese Auflösung in der Firmware oder doch in FHEM stattfindet.
Beides. Alle SCCs sind ueber eine bzw. die gleiche Leitung angebunden. Wenn ein SCC ein * sieht, weiss, dass die Nachricht nicht fuer ihn ist, nimmt ein * weg, und sendet es eins weiter (bzw. "hoeher"). Wenn eine Nachricht von "oben" kommt, dann wird ein * davogepackt, und nach unten weitergereicht.
Vermutlich hat Bjoern/a-culfw noch nie von einem SCC gehoert, und derjenenige, der a-culf auf SCC portiert hat, das Konzept nicht verstanden.
Zitat von: rudolfkoenig am 07 Dezember 2015, 08:30:22
set SCC1 raw T011234
Aeh: das hast du bisher verschwiegen, oder ich hatte Tomaten auf den Augen.
Bitte mit Bjoern/etc weiter debuggen, ich bin raus.
Beides. Alle SCCs sind ueber eine bzw. die gleiche Leitung angebunden. Wenn ein SCC ein * sieht, weiss, dass die Nachricht nicht fuer ihn ist, nimmt ein * weg, und sendet es eins weiter (bzw. "hoeher"). Wenn eine Nachricht von "oben" kommt, dann wird ein * davogepackt, und nach unten weitergereicht.
Vermutlich hat Bjoern/a-culfw noch nie von einem SCC gehoert, und derjenenige, der a-culf auf SCC portiert hat, das Konzept nicht verstanden.
Hallo Rudi,
zuerst einmal entschuldige, ich wollte da keine Informationen zurück halten. Ich hatte das mit der alternativen Firmware in einem anderen Bereich erwähnt, in der Diskussion mit Dir nicht, sorry!
Aber wie Du hier lesen kannst:
http://forum.fhem.de/index.php/topic,35064.msg366074.html#msg366074
habe ich das Verhalten mit der Standard Firmware ebenfalls nachvollziehen können. Ich vermute daher, dass es nicht an der alternativen Firmware liegt, sondern ein grundsätzliches Problem ist.
Kannst Du mir einen Tipp geben, in welcher Datei der Firmware diese Logik abgebildet wird? Dann schaue ich da mal rein.
Danke!
Gruss
Ist einfach zu finden: in culfw/Devices/SCC/SCC.c verweist '*' auf stacking_func, was in clib/stacking.c zu finden ist. Ist mWn von busware direkt, ich habe sie jetzt zum ersten mal gesehen.
Hallo Rudi,
danke für den Tip.
Ich habe jetzt mal etwas in der Firmware gegraben und dabei auch mal andere Versionen probiert. Mit der culfw in der Version 1.60
http://sourceforge.net/p/culfw/code/HEAD/tree/tags/CUL_VER_160/
funktioniert das Schalten noch problemlos. Flashe ich dann die Version 1.61
http://sourceforge.net/p/culfw/code/HEAD/tree/tags/CUL_VER_161/
schaltet nichts mehr. Ich habe dann mal nach den Unterschieden gesucht und festgestellt, dass ab der Version 1.61 die Konstante "HAS_IT" definiert ist, welche dann wiederum unter anderem in der Datei "clib/rf_receive.c" in Zeile 809 abgefragt wird. Nach dem Einfügen des Codes
reset_input();
in Zeile 824 (vor dem "return") dieser Datei geht das Schalten dann wieder. Allerdings weiss ich nicht was damit dann kaputt geht und andererseits funktioniert diese Änderung in der aktuellen culfw 1.65 nicht mehr, da die Datei ganz anders aussieht. Da ich mich in der Firmware so überhaupt nicht auskenne wäre die Frage, wer mir da weiterhelfen kann um das Problem weiter einzugrenzen und/oder zu lösen. Es scheint auf jeden Fall etwas mit der Firmware zu tun zu haben, das ist die Schlussfolgerung, die ich aus meinen Debugging-Sessions der letzten Tage ziehen konnte. Weiterhin ist damit auch die alternative Firmware ausgeschlossen, da ich hier mit der original Dateien aus dem Repository gearbeitet habe. Vielleicht fällt Dir ja noch etwas ein, was an Änderungen damals gemacht wurde, die zu meinem Problem führen könnten.
Danke!
Gruss
ZitatNach dem Einfügen des Codes
reset_input();
in Zeile 824 (vor dem "return") dieser Datei geht das Schalten dann wieder.
Schwer zu glauben. rf_receive.c ist nur fuer den Empfang zustaendig (nicht senden), und durch einfuegen dieser Zeile hast du nur den IT-Empfang unmoeglich gemacht: Falls IT erkannt wurde, dann setzt reset_input den Status wieder auf RESET, und der Automat faengt damit wieder von vorne an, und verpasst damit die Sync-Bits.
Ich kann rf_receive.c seit dem Einbau von ESA, TCM97001, REVOLT und IT leider kaum mehr verstehen: kann sein, dass ich was uebersehe.
Ist inzwischen sicher, dass * ordentlich weitergeleitet wird?
Zitat von: rudolfkoenig am 09 Dezember 2015, 08:27:08
Schwer zu glauben. rf_receive.c ist nur fuer den Empfang zustaendig (nicht senden), und durch einfuegen dieser Zeile hast du nur den IT-Empfang unmoeglich gemacht: Falls IT erkannt wurde, dann setzt reset_input den Status wieder auf RESET, und der Automat faengt damit wieder von vorne an, und verpasst damit die Sync-Bits.
Ich kann rf_receive.c seit dem Einbau von ESA, TCM97001, REVOLT und IT leider kaum mehr verstehen: kann sein, dass ich was uebersehe.
Ist inzwischen sicher, dass * ordentlich weitergeleitet wird?
Hallo Rudi,
ich denke meine Änderung hat einfach irgend einen Teil, der IT-spezifisch ist, deaktiviert, und deswegen funktionierte es. Mir kam es auch komisch vor, aber so viele Änderungen gab es nicht zwischen 1.60 und 1.61.
Das "*" wird korrekt weiter geleitet. Das, was in der "CUL_SimpleWrite" raus geht, hat genau 1 "*" vorangestellt bei mir, was richtig ist.
Mein Problem ist nun, dass ich nicht weiss, wie ich weiter machen kann. Ich würde auch mein System zur Verfügung stellen zum Debugging, falls erforderlich. Entweder über VPN oder Teamviewer, allerdings weiss ich nicht, wer das weiter debuggen könnte...
Gruss
Gruss
Hallo Rudi,
ich vermute, dass Du bei dem Problem ebenfalls ratlos bist. Aktuell verwende ich einen 868 SCC zum Senden der 433 Befehle, den 433 SCC nur zum Empfang. Trotzdem ist das natürlich nicht das, was ich erreichen wollte. Falls Dir noch was einfällt, sag bitte bescheid.
Gruss
Ich kann dir keine schnelle Loesung bieten.
Ich wuerde debug-Ausgbauen im Firmware einbauen, und mit einem direkten Zugang (z.Bsp. screen) versuchen das Problem zu lokalisieren. Ist sicher keine triviale Angelegenheit.