Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.41

[Bastel-Frank]

Hallo Frank,

Michael hat den Support für tsculfw jetzt in sein Firmware Update Tool 1.03 eingebaut.
Damit könntest Du einen neuen Versuch starten, ohne CUL umflashen zu müssen.

Gruß, Ansgar.

Hallo Ansgar,

vielen Dank für die Info. Ich werde die neue Version testen.

Viele Grüße
Frank

[noansi]

Hallo Theo,

Oder hängt sich das FHEM wegen dem MyUtils auf? Darin habe ich aktuell aber nur den Addlog. Ich deaktiviere diesen einmal zum Test.

Wenn da ein Bug drin steckt, kann das auch zu Deinem Problem führen oder zumindest den Log Eintrag dazu erklären.

Gruß, Ansgar.

[schka17]

Hallo,

da ich sukzessive von SlowRF alles auf Homematic umstelle, benötige ich weitere IO Devices, ich habe da jetzt dieses geniale LGW mit CoProzessor, darauf habe ich bis jetzt a-culfw laufen, damit geht aber im HM Bereich so gut wie gar nichts, jetzt will ich mal TSCUL verwenden aber es gibt leider keine hex Datei für den mini, nur nano. Jetzt will ich mir das selber kompilieren (weiss zwar noch nicht wie), reicht es eigentlich wenn ich die board.h vom mini verwende oder muss ich da mehr ändern?

Gruß

Karl

[noansi]

Hallo Karl,

hier https://forum.fhem.de/index.php/topic,24436.msg529649.html#msg529649 habe ich in TSCUL_fwcode_00_06_FHEM_Modules_00_06m.zip mal auf Basis der nanoCUL Variante eine miniCUL Variante gebaut. Testen kann ich sie leider nicht.

Auch diese verwendet SPI_CC1101_READ_SPECIAL_PORT Port B Pin 6 als ungenutzten Pin. Falls dieser Pin doch genutzt ist, muss das geändert werden, sprich auf einen ungenutzten I/O Pin in board.h angepasst werden.

Es wird ein Version für Marker Pins gebaut. Damit bei unbeschalteten Pins eine 868MHz Version. Mit 433MHz Rf Modul macht es wohl weniger Sinn.

Bitte gib Feedback, ob es funktioniert.

Gruß, Ansgar.

[schka17]

Hallo Karl,

hier https://forum.fhem.de/index.php/topic,24436.msg529649.html#msg529649 habe ich in TSCUL_fwcode_00_06_FHEM_Modules_00_06m.zip mal auf Basis der nanoCUL Variante eine miniCUL Variante gebaut. Testen kann ich sie leider nicht.

Auch diese verwendet SPI_CC1101_READ_SPECIAL_PORT Port B Pin 6 als ungenutzten Pin. Falls dieser Pin doch genutzt ist, muss das geändert werden, sprich auf einen ungenutzten I/O Pin in board.h angepasst werden.

Es wird ein Version für Marker Pins gebaut. Damit bei unbeschalteten Pins eine 868MHz Version. Mit 433MHz Rf Modul macht es wohl weniger Sinn.

Bitte gib Feedback, ob es funktioniert.

Gruß, Ansgar.

Hallo Ansgar,

Ich hoffe ich komme spätestens am Wochenende dazu, bekomme gerade meine neue Heizung. Ich probiere das aus, aber ich habe das schon richtig verstanden dass ich "nur" die board.h anpassen müsste? Soviel ich im ersten schnellen durchsehen bei der a-culfw gesehen gibts nur dort Unterschiede in der Pinbelegeung.

Gru, Karl


Sent from my iPad using Tapatalk

[noansi]

Hallo Karl,

Ich probiere das aus, aber ich habe das schon richtig verstanden dass ich "nur" die board.h anpassen müsste?

Unter Devices habe ich "miniCUL" erstellt.
Ich habe board.h, miniCUL.c und makefile nach miniCUL aus der a-culfw angepasst.

Wenn Irren nicht menschlich wäre, dann müßtest Du dort nur compilieren und flashen. 

Danach ergibt sich dann die Frage, ob TSCUL damit läüft, bzw. auf miniCUL zugreifen kann.

Gruß, Angar.

[schka17]

Hallo Karl,

Unter Devices habe ich "miniCUL" erstellt.
Ich habe board.h, miniCUL.c und makefile nach miniCUL aus der a-culfw angepasst.

Wenn Irren nicht menschlich wäre, dann müßtest Du dort nur compilieren und flashen. 

Danach ergibt sich dann die Frage, ob TSCUL damit läüft, bzw. auf miniCUL zugreifen kann.

Gruß, Angar.

Hallo Angar,

schnelles erstes Feedback,

Code Auswählen Erweitern

2017.01.27 10:01:51 1: LGW2_TSCUL is VERSION_TS, VTS 0.06 miniCUL, miniCUL_V1.x
2017.01.27 10:04:05 2: TSCUL_condUpdate: LGW2_TSCUL new condition init
2017.01.27 10:04:05 1: LGW2_TSCUL is VERSION_TS, VTS 0.06 miniCUL, miniCUL_V1.x
2017.01.27 10:04:05 1: DevIoTS_OpenDev: 192.168.255.17:85 reappeared (LGW2_TSCUL)
2017.01.27 10:04:08 4: TSCUL_Parse: LGW2_TSCUL K971450860073C705 -71.5
2017.01.27 10:04:33 2: TSCUL_Parse: LGW2_TSCUL: unknown message T1F5E00B6FFF9


Soweit glaube ich dass man die Frage beantworten kann, konnte kompilieren, flashen und darauf zugreifen. Jetzt noch meinen CUL flashen und dann weiter damit beschäftigen. Vielen Dank jedenfalls für diese rasche Unterstützung.

Sollte noch jemand versuchen einen miniCUL auf einem LGW betreiben zu wollen, kompilieren mit

Code Auswählen Erweitern

make program
kommt dann natürlich eine Fehlermeldung weill der mini ja nicht angesteckt ist, flashen auf das LGW mit

Code Auswählen Erweitern

curl --http1.0 -H "Content_Type:multipart/form-data" -F "file=@./TSminiCUL.hex; filename=addon.hex" http://192.168.255.17/ota/addon.hex

Gruß, Karl

[noansi]

Hallo Karl,

neben einer KS Nachricht ist auch eine FHT-artige Nachricht in Deinem Protokoll angekommen.

FHT hatte ich in 00_TSCUL.pm auskommentiert, da meinerseits untestbar.
Außerdem ist es in miniCUL genau wie nanoCUL weitgehend abgeschaltet um RAM für die HM Puffer bereit zu stellen.

Wenn Du also doch  irgendwas mit den FHT Nachrichten anfangen möchtest, dann wären noch Änderungen nötig und da nur 2kB RAM zur Verfügung stehen geht wohl nicht alles mit dem miniCUL.

Aber natürlich kannst Du auch testen, ob der SlowRF Empfang besser oder schlechter ist, als mit den anderen Firmware Alternativen.
KS Sensoren habe ich auch im Einsatz und daher auch im SlowRF Bereich Änderungen einfließen lassen.

Wenn Du bei den KS Sensoren keine V1.1 Sensoren hast, dann solltest Du HAS_NO_WS2000_V1_1_SUPPORT  in der board.h definieren, was Fehlempfang für V1.2 verbessert, da bei V1.1 die Checksummenabsicherung schwächer ist, als beim V1.2 Protokoll und daher mehr "Schrott" durchkommt.

Gruß, Ansgar.

[schka17]

Hallo Karl,

neben einer KS Nachricht ist auch eine FHT-artige Nachricht in Deinem Protokoll angekommen.

FHT hatte ich in 00_TSCUL.pm auskommentiert, da meinerseits untestbar.
Außerdem ist es in miniCUL genau wie nanoCUL weitgehend abgeschaltet um RAM für die HM Puffer bereit zu stellen.

Wenn Du also doch  irgendwas mit den FHT Nachrichten anfangen möchtest, dann wären noch Änderungen nötig und da nur 2kB RAM zur Verfügung stehen geht wohl nicht alles mit dem miniCUL.

Aber natürlich kannst Du auch testen, ob der SlowRF Empfang besser oder schlechter ist, als mit den anderen Firmware Alternativen.
KS Sensoren habe ich auch im Einsatz und daher auch im SlowRF Bereich Änderungen einfließen lassen.

Wenn Du bei den KS Sensoren keine V1.1 Sensoren hast, dann solltest Du HAS_NO_WS2000_V1_1_SUPPORT  in der board.h definieren, was Fehlempfang für V1.2 verbessert, da bei V1.1 die Checksummenabsicherung schwächer ist, als beim V1.2 Protokoll und daher mehr "Schrott" durchkommt.

Gruß, Ansgar.

Hallo Ansgar,

Die FHT's werden sowieso abgebaut, der miniCUL ist ausschließlich für Homematic vorgesehen da ich eben immer mehr HM Komponenten habe, gehen die IO device immer in Overload wenn ich z.b. heizprofile umstelle. Da möchte ich den Funkverkehr auf mehrere HM IO aufteilen. Für slowrf habe ich einen CUNO. Ich muss mich da jetzt mal rantasten, ich dachte mir dass mal alles auskommentiere was nicht mit HM zu tun, aber so wie es jetzt schon läuft bin ich mega zufrieden. Möglicherweise nur ein Schönheitsfehler, aber es gibt natürlich den miniCUL nicht als model in 00_TSCUL.pm, weiss nicht ob das einen Impact hat, bemerket habe ich nichts, also so weit mal so gut. Jetzt ist mal die Integration der neuen Heizung mit ebus an der Reihe, vielen Dank für den Support.

Gruß, Karl


Sent from my iPad using Tapatalk

[noansi]

Hallo Karl,

aber es gibt natürlich den miniCUL nicht als model in 00_TSCUL.pm, weiss nicht ob das einen Impact hat

nein 

Gruß, Ansgar

[sledge]

Habe die neue FW auf zwei LGW mit miniCUL erfolgreich am Start - läuft bisher (~20h) problemlos.

Hänge die addon.hex (VTS 0.06 miniCUL) für den miniCUL mal an, hat ja ggfs. nicht jeder die avr-Toolchain griffbereit.

Gruß, Tom

[dieter]

 .

[b4rRa]

Moin Moin Kann man die vorkompilierte TSnanoCUL.hex in der ZIP File ohne Probleme flashen? Sprich ist die schon auf 868 eingestellt und HM optimiert, oder sollte ich mir diese besser selbst kompilieren und in der board.h noch etwas anpassen?

[noansi]

Hallo b4rRa,

wenn Du nicht von der Bauanleitung abgewichen bist, dann sollte es passen, da hier im Thread schon getestet.

Gruß, Ansgar.

[hanoba]

Mir wurde im Thread https://forum.fhem.de/index.php/topic,64375.msg555971.html#msg555971 geraten, die TSCUL-Firmware zu probieren. Leider hat TSCUL keine Verbesserung, sondern eine Verschlechterung gebracht (Details im oben genannten Thread).

Zu den erzeugten TSCUL-Log-Files hätte ich ein paar Fragen:
- Was bedeutet TSCUL_send und TSCUL_parse genau (siehe Beispiel unten)?
  TSCUL_send:  nanoCul                                           As 0E 3E B011 133A3C 35F481 0205000000
  TSCUL_Parse: nanoCul  139750 A FF13 08120968 01 0E 3E B011 133A3C 35F481 02 _bst _CCAdly:4 -138
- Was ist "139750 A FF13" im Beispiel oben? Timestamp?
- Was bedeuten  "_bst"
- Was bedeutet "_CCAdly:4"
- Was bedeutet: "TSCUL_XmitDlyHM:  nanoCul  id:35F481 dDly:95 toms:33"
- Was bedeutet: "_dhmSt"

Vielleicht kann hier jemand weiterhelfen.

Danke und Gruß

Harald