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

[noansi]

Hallo Ambiman,

hast Du die Firmware aus culfw-code-459-trunk_lufa_rf_cr_sd_75_63.zip installiert?
Da ist mir bei der letzten Umstellung der Kommandointerpretation it_func leider durch die Lappen gegangen und daher wird damit IT sicher nicht gesendet. Das werde ich noch korrigieren.

Geht es mit der aus culfw-code-459-trunk_lufa_rf_cr_sd_75_58.zip?

Ich habe leider kein IT device um Testen zu können und bin daher auf möglichst aussagekräftiges Feedback dazu angewiesen.

Gruß, Ansgar.

[noansi]

Hallo Ambiman,

hier mal eine neue Version zum Testen, ob IT jetzt klappt. Für das Senden ist jetzt auch IT-V3 drin, aber noch nicht für den Empfang.

Ich habe noch ungetestete Änderungen bezüglich Netzwerk darin, also bei CUNO2 kann es noch zu Netzwerkproblemen kommen.

Gruß und frohes Neues,

Ansgar.

[ambiman]

Hallo Ansgar,

besten Dank - Firmware geflashed on deine FHEM Module wieder installiert - das IT-Schalten funktioniert jetzt wie gewünscht .
Folgende FM erhalte ich jedoch noch im Log - woher kommen diese ?

Code Auswählen Erweitern


016.01.01 19:45:00 3: CUL_0: Unknown code ERR:ASKSINSFRX, help me!
2016.01.01 19:45:00 3: CUL_0: Unknown code ERR:ASKSINIDLERX, help me!
2016.01.01 19:45:04 2: IT set Schalter_Teich_LED off
2016.01.01 19:45:06 2: IT set Schalter_Teich_LED on


[ambiman]

Zusatz:

Beim einem set on-for-timer 2 bei einem HM-LC-SW1-BA-PCB mit AES-Signatur erhalte ich folgende Meldung - das eigentliche Schalten funktioniert jedoch:

Code Auswählen Erweitern


2016.01.01 20:04:12 3: CUL_HM set Alarmgeber_Piezo_Flur on-for-timer 2
2016.01.01 20:04:12 3: CUL_send:  CUL_0  id:3C9821 dDly:84
2016.01.01 20:04:13 2: CUL_ParseTsHM CUL_0 illegal message received: AFF2300024F8A001902A00327D0E23C98211c934e1906380d1dc2d65a9897a75e6780


[ambiman]

Die anderen Meldungen tauchen scheinbar sporadisch auf:

Code Auswählen Erweitern


2016.01.01 20:56:15 3: CUL_0: Unknown code ERR:ASKSINSFRX, help me!
2016.01.01 20:56:15 3: CUL_0: Unknown code ERR:ASKSINIDLERX, help me!


[noansi]

Hallo Ambiman,

prima, dass IT jetzt bei Dir funktioniert.  Den Empfang von IT-V3 muss ich noch einbauen, damit das komplett so tut, wie die normale Firmware.

Zu den Meldungen (da hilft ein Blick in den Code, wenn C geläufig ist):
- ERR:ASKSINSFRX -> cc1101 Transiever Überlauf des Empfangspuffers in ASKSIN (HM Mode)
- ERR:ASKSINIDLERX -> cc1101 Transiever in IDLE nach RX statt wieder RX, direkt nach vorheriger Meldung aber nur ein "Folgefehler"

Also erst mal nicht so schlimm, da offenbar Daten zu kurz aufeinander empfangen wurden und nicht rechtzeitig auf CUL vom cc1101 abgeholt werden konnten. Hängt auch an der Anzahl der Devices, die senden.

2016.01.01 20:04:13 2: CUL_ParseTsHM CUL_0 illegal message received: AFF2300024F8A001902A00327D0E23C98211c934e1906380d1dc2d65a9897a75e6780

Hier ist was merkwürdiges passiert, da kleine Hex Ziffern in/an einer HM Nachricht kommen. Die kommen aber vermutlich nicht von CUL und nicht von meinem Code, so weit ich das sehe?!?

Bist Du schon bei FHEM 5.7 ? Dazu kann ich nicht sagen ob meine Modul Varianten Probleme bereiten können.
Bei AES war ich noch nicht. Und meine 00_CUL.pm Variante kennt das noch nicht. Von daher kann das mit AES zusammen hängen.

Benutzt Du CUL_V3 oder CUNO2?
Möglich wäre hier noch ein Puffer Problem (bei CUNO2 kann das u.U. passieren) so dass ein Teil einer Nachricht ankommt, dann etwas fehlt und wieder was anderes nicht vollständig kommt und daher auch der LF dazwischen fehlt.

Gruß, Ansgar.

[ambiman]

Hallo Ansgar,


die illegal message Events tauchen nun häufiger auf - anbei ein kleiner Auszug aus dem Log:

Code Auswählen Erweitern


AFF1301E9D122001932A00327D0E238F2A9e88df545d8493df70f1d7aa791ae219180
2016.01.04 19:03:59 3: CUL_0: Unknown code :CUL_0, help me!
2016.01.04 19:03:59 3: CUL_send:  CUL_0  id:38F2A9 dDly:84
2016.01.04 19:03:59 3: CUL_ParseTsHM: CUL_0  id:38F2A9 dhmSt:104
2016.01.04 19:03:59 3: CUL_send:  CUL_0  id:38F2A9 dDly:79
2016.01.04 19:03:59 2: CUL_ParseTsHM CUL_0 illegal message received: AFF1301E9D163001933A00327D0E238F2A9edb1b08e6fe0d8eb1dce2be5a40ec9de80
2016.01.04 19:03:59 3: CUL_0: Unknown code :CUL_0, help me!
2016.01.04 19:04:01 3: CUL_send:  CUL_0  id:3CDBBB dDly:82
2016.01.04 19:04:01 3: CUL_ParseTsHM: CUL_0  id:3CDBBB dhmSt:104
2016.01.04 19:04:01 3: CUL_send:  CUL_0  id:3CDBBB dDly:86
2016.01.04 19:04:01 3: CUL_ParseTsHM: CUL_0  id:3CDBBB dhmSt:104
2016.01.04 19:04:02 3: CUL_send:  CUL_0  id:3CDBBB dDly:85
2016.01.04 19:04:02 2: CUL_ParseTsHM CUL_0 illegal message received: AFF1301E9D2A4001916A00327D0E23CDBBB9a8a9b5b6f590553fa4278c8c0b4afac80
2016.01.04 19:04:02 3: CUL_0: Unknown code :CUL_0, help me!
2016.01.04 19:04:02 3: CUL_send:  CUL_0  id:3CDBBB dDly:83
2016.01.04 19:04:02 3: CUL_ParseTsHM: CUL_0  id:3CDBBB dhmSt:104
2016.01.04 19:04:02 3: CUL_send:  CUL_0  id:3CDBBB dDly:79
2016.01.04 19:04:02 2: CUL_ParseTsHM CUL_0 illegal message received: AFF1301E9D2E5001917A00327D0E23CDBBB2358c63e883dbc21447f792d11972f6380
2016.01.04 19:04:02 3: CUL_0: Unknown code :CUL_0, help me!
2016.01.04 19:04:02 3: CUL_send:  CUL_0  id:3CDBBB dDly:82
2016.01.04 19:04:02 3: CUL_ParseTsHM: CUL_0  id:3CDBBB dhmSt:104
2016.01.04 19:04:03 3: CUL_send:  CUL_0  id:3CDBBB dDly:86
2016.01.04 19:04:03 2: CUL_ParseTsHM CUL_0 illegal message received: AFF1301E9D327001918A00327D0E23CDBBBe90c45aabb468896bbe12a59aa40263f80
2016.01.04 19:04:03 3: CUL_0: Unknown code :CUL_0, help me!



Ja, ich nutze bereits FHEM 5.7 - anbei noch einige Infos zu meinen Versionen:

Code Auswählen Erweitern



   TYPE       CUL
   VERSION    V 99.75 CUL868
   VERSION_HW CUL_V3.4


File             Rev   Last Change

fhem.pl          10298 2015-12-29 19:08:19Z rudolfkoenig 
00_CUL.pm         6526 2014-09-09 15:12:39Z thomyd
10_CUL_HM.pm     10265 2015-12-26 10:47:19Z martinp876


Ich vermute es hängt mit den AES-Signaturen von Homematic zusammen?

Viele Grüße,

ambiman

[noansi]

Hallo Ambiman,

probier bitte mal die angehängte 00_CUL.pm

Damit verschwindet zumindest die "illegal message received" Fehlermeldung, weil die Kleinbuchstaben bei meinem Timestamp perl Code erlaubt werden.
Es sind alles Sendequittungen mit Sendetimestamp in Deinen Logs. Die kommen nach dem Senden mit Sendezeitstempel im Original wieder zurück von CUL.
Es werden wohl von AES Nachrichten mit Kleinbuchstaben im HEX Code an CUL gesendet, denke ich. Damit kommt CUL zurecht.

Gruß, Ansgar.

[ambiman]

Hallo Ansgar,

es gibt scheinbar noch ein Problem mit IT(v3):

Ich habe gestern ein paar Intertechno ITR-1500 im SET erworben und wollte dieses anlernen wie im Wiki (das bezieht sich jedoch auf ITv1) beschrieben, also IT-Code auswählen und dann in der Lernphase schalten - leider erfolglos

Also habe ich mir die letzte Version der aculfw besorgt (a-culfw_1.20.01_build_176_master) und auf meinen CUL868 die CUL_V3_433MHZ Firmware geflashed (die 868er Version schaltet die Frequenz scheinbar nicht um) und anschließend den CUL statisch auf 433.92Mhz im RFMode SlowRF gesetzt und autocreate aktiviert. Den Knopf an der Original Intertechno-Fernbedienung gedrückt und schon war das IT-Device  (als ITv3) in FHEM zu sehen.

Nun da ich die IT-Definition hatte dachte ich, dass ich deine Firmware wieder verwenden kann um die Dose zu schalten - leider hat dies nicht funktioniert

Anbei einige Logs mit beiden Firmwares:

Deine Firmware:

Code Auswählen Erweitern



2016.01.07 12:11:20 2: IT set WZ_Stehlampe on
2016.01.07 12:11:20 4: CUL_send:  CUL_0                            is 00 11 1100 100110 010000 101110010000
2016.01.07 12:11:22 2: IT set WZ_Stehlampe off
2016.01.07 12:11:22 4: CUL_send:  CUL_0                            is 00 11 1100 100110 010000 101110000000
2016.01.07 12:11:24 2: IT set WZ_Stehlampe on
2016.01.07 12:11:24 4: CUL_send:  CUL_0                            is 00 11 1100 100110 010000 101110010000
2016.01.07 12:11:26 2: IT set WZ_Stehlampe off
2016.01.07 12:11:26 4: CUL_send:  CUL_0                            is 00 11 1100 100110 010000 101110000000



A-CULFW:

Code Auswählen Erweitern



2016.01.07 12:16:22 2: IT set WZ_Stehlampe off
2016.01.07 12:16:22 4: CUL_send:  CUL_0                            is 00 11 1100 100110 010000 101110000000
2016.01.07 12:16:23 2: IT set WZ_Stehlampe on
2016.01.07 12:16:23 4: CUL_send:  CUL_0                            is 00 11 1100 100110 010000 101110010000
2016.01.07 12:16:24 2: IT set WZ_Stehlampe off
2016.01.07 12:16:24 4: CUL_send:  CUL_0                            is 00 11 1100 100110 010000 101110000000



Im Moment nutze ich somit die aculfw in der 433er Variante, da damit scheinbar ITv1/v3 und Homematic funktioniert - zumindest bisher.

Wäre klasse, wenn deine Firmware das ebenfalls unterstützen würde, da du - wenn ich es richtig verstanden habe - einige Verbesserungen bzgl. Timing und HM implementiert hast.

Wie oft kann man den CUL eigentlich flashen, bis der EEPROM kaputt ist ?

Viele Grüße,

ambiman

[noansi]

Hallo Ambiman,

blöd, wenn man keine Hardware zum selber Testen hat. 

Danke für den Log Auszug. Das hat mich einem Problem näher gebracht. IT_V3 ist wohl an 32 Tri-State Bits zu erkennen und nicht an 31, wie ich dem aktuellen CUL FW Code anhand eines falschen Kommentares glaubte entnehmen zu können.
Deswegen wurde sicherlich mit falschem Timing (aber richtiger Frequenz) gesendet.

Da ich nun einen Blick in den A-CULFW code genommen habe, muss ich die IT_V3 Unterschiede auch mal durchgehen, um das entsprechend umzusetzen, was bei Dir sendetechnisch funktioniert. Das dauert noch etwas.

Wie oft kann man den CUL eigentlich flashen, bis der EEPROM kaputt ist ?

10000 Lösch-/Schreibzyklen gibt Atmel im Datenblatt an.

einige Verbesserungen bzgl. Timing und HM

Für HM habe ich die Möglichkeit 8ms genauen Sendetimings eingebaut. Und auf FHEM Seite das Ausmessen der IO-Timings, um das Antwortiming zu verbessern. Das klappt auch gut, sofern FHEM nicht zu lange "rumbummelt" und die Sendebefehle rechtzeitig raus schickt (und man keinen HM-Repeater verwendet. Das ist Baustelle, sofern lösbar).

Aber die Änderungen an der Firmware gehen mittlerweile noch wesentlich weiter. SlowRF Empfang ist umgeschrieben. USB-, Seriell-, Stacking- und Netzwerk Kommunikation sind umgeschrieben und stabilisiert.
Die CC1101 Transceiver Programmierung ist umgeschrieben und korrigiert bei Problemen mit der Frequenzsynthesizer Kalibrierung. Usw.
Mein Ziel ist, das was läuft (insbesondere mit meiner verfügbaren Hardware) auch wirklich zuverlässig funktionierend umzusetzen und dann andere Protokolle zu ergänzen.

Gruß, Ansgar.

[noansi]

Hallo Ambiman,

angehängt eine neue Version zum Testen.

Ich hoffe, Intertechno_V3 Senden klappt nun auch. Home Easy habe ich auch mit in die Firmware eingebaut, so wie ich es in der A-Firmware vom Timing her gesehen habe, als ich dort nach IT_V3 geschaut habe. Ich hoffe beides klappt, da ich die mangels Hardware nicht testen kann.
Für Intertechno_V1 habe ich noch Funkschalter als Testopbjekte ausgraben können. Die funktionieren.

Wegen Flashspeicher Knappheit ist jedoch RF Mbus bei CUl_V3 nicht enhalten. Kann jedcoh mit Änderung der board.h unter Verzicht auf anderes umkonfiguriert und neu compiliert werden. Ich hoffe, ich finde noch ein paar Bytes, um das wieder rein zu bekommen.

Außerdem habe ich den ASKSIN Task überarbeitet und denke, damit noch weniger Empfangspakete zu verlieren.
Dabei nutze ich auch einen ungenutzten Eingang/Ausgang als schnelles Speicherflag. Daher muss gegen Schaltplan und/oder Hardware geprüft werden, ob der auch wirklich ungenutzt ist. Für CUL, COC, SCC und CUNO2 kann ich das mit Plänen von der Busware Seite und verfügbarer Hardware, nicht jedoch für andere Hardware.

Bei CUL_V3.hex ist rf_mbus wegen Flash-Speichermangel nicht enthalten. Ich hoffe, mir fallen noch genügend Speicheroptimierungen auf, um das wieder ändern zu können. Natürlich besteht die Möglichkeit des neu Compilierens mit geänderter Protokoll-Zusammensetzung.

Für die Paketversandprotokolle wie auch RF-Router habe in rf_credits.c eine credits Brechnungsfunktion mit Subcredits ergänzt. Als Ansatz für eine Creditsberechnungsvereinheitlichung (und auf der Suche nach verschwendetem Flash Speicher).

In 00_CUL.pm werden nun auch die eingebauten ASKSIN Fehlermeldungen abgefangen und bei verbose=2 ausgegeben.

Für den SPI Zugriff habe ich einige Assembler Routinen zum Buffer Lesen/Schreiben des CC1101 und auch des ENC28J60 ergänzt. Diese berücksichtigen das Timing beim SPI-Zugriff um etwas schnelleren Zugriff zu ermöglichen. Beim Ping zu CONO2 hat sich damit eine deutliche Verbesserung in der Antwortzeit ergeben. Ethernet bei CUNO2 läuft bei mir nun auch stabil.

Gruß, Ansgar.

PS: Damit es klar bleibt. Da ich schon länger kein FHEM Update mehr fahren kann, beruhen die Moduländerungen in FHEM_module_changed.zip auf einem Stand von Ende 2014. Also unbedingt erst ein Backup der alten Dateien machen bevor sie ersetzt werden!
Außerdem natürlich den letzten offiziellen Stand der Firmware bereit halten, falls es unerwünscht läuft!

PS2: WICHTIG! Bei RF-Router scheint in der Firmware oder in CUL/STACKABLE noch was schief zu laufen. Ein Versuch mit RF-Router hat bei mir zu einem fast hängenden FHEM und neu startendem SCC geführt. Also bitte den nicht testen.
Nur durch ein Abschalten von RF-Router in 00_CUL.pm DoInit habe ich beiden CULs wieder zu normaler Reaktion bewegen können.

[noansi]

Hallo Testwillige,

angehängt eine neue Version zum Testen.

Bei der letzten Version hat sich in der Firmware ein Fehler eingeschlichen, der bei RF-Router und FastRF zu einer Endlosschleife geführt hat, was wiederum watchdog Neustarts von CUL bewirkte. Das ist behoben. Richtig testen konnte ich beide jedoch nicht. Aber FHEM wird nicht mehr dadurch blockiert.
Au0erdem hatte ich modifizierte DevIo.pm nicht beigepackt.

Ich hoffe, Intertechno_V3 Senden klappt nun auch. Home Easy habe ich auch mit in die Firmware eingebaut, so wie ich es in der A-Firmware vom Timing her gesehen habe, als ich dort nach IT_V3 geschaut habe. Ich hoffe beides klappt, da ich die mangels Hardware nicht testen kann.
Für Intertechno_V1 habe ich noch Funkschalter als Testobjekte ausgraben können. Die funktionieren.

Wegen Flashspeicher Knappheit ist jedoch RF Mbus bei CUl_V3 nicht enhalten. Kann jedcoh mit Änderung der board.h unter Verzicht auf anderes umkonfiguriert und neu compiliert werden. Ich hoffe, ich finde noch ein paar Bytes, um das wieder rein zu bekommen.

Außerdem habe ich den ASKSIN Task überarbeitet und denke, damit noch weniger Empfangspakete zu verlieren.
Dabei nutze ich auch einen ungenutzten Eingang/Ausgang als schnelles Speicherflag. Daher muss gegen Schaltplan und/oder Hardware geprüft werden, ob der auch wirklich ungenutzt ist. Für CUL, COC, SCC und CUNO2 kann ich das mit Plänen von der Busware Seite und verfügbarer Hardware, nicht jedoch für andere Hardware.

Bei CUL_V3.hex ist rf_mbus wegen Flash-Speichermangel nicht enthalten. Ich hoffe, mir fallen noch genügend Speicheroptimierungen auf, um das wieder ändern zu können. Natürlich besteht die Möglichkeit des neu Compilierens mit geänderter Protokoll-Zusammensetzung.

Für die Paketversandprotokolle wie auch RF-Router habe in rf_credits.c eine credits Brechnungsfunktion mit Subcredits ergänzt. Als Ansatz für eine Creditsberechnungsvereinheitlichung (und auf der Suche nach verschwendetem Flash Speicher).

In 00_CUL.pm werden nun auch die eingebauten ASKSIN Fehlermeldungen abgefangen und bei verbose=2 ausgegeben.

Für den SPI Zugriff habe ich einige Assembler Routinen zum Buffer Lesen/Schreiben des CC1101 und auch des ENC28J60 ergänzt. Diese berücksichtigen das Timing beim SPI-Zugriff um etwas schnelleren Zugriff zu ermöglichen. Beim Ping zu CONO2 hat sich damit eine deutliche Verbesserung in der Antwortzeit ergeben. Ethernet bei CUNO2 läuft bei mir nun auch stabil.

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar.

PS: Damit es klar bleibt. Da ich schon länger kein FHEM Update mehr fahren kann, beruhen die Moduländerungen in FHEM Modulen auf einem Stand von Ende 2014. Also unbedingt erst ein Backup der alten Dateien machen bevor sie ersetzt werden! Mit FHEM 5.7 kann ich gar nicht testen, ob es zu Problemen kommt.
Außerdem natürlich den letzten offiziellen Stand der Firmware bereit halten, falls es unerwünscht läuft!

[noansi]

Hallo Testwilige,

angehängt eine Aktualisierung von 00_CUL.pm für meine Testversion. Sie filtert Messages von HM-Repeater aus, um das Verzögerungstiming nicht zu stören.
HM-Repeater wird somit erst mal nicht unterstützt. Knackpunkt ist die Repeater Verzögerung, die ein sehr knappes Verzögerungstiming zu erfordern scheint.

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar.

PS: Damit es klar bleibt. Da ich schon länger kein FHEM Update mehr fahren kann, beruhen die Moduländerungen in FHEM Modulen auf einem Stand von Ende 2014. Also unbedingt erst ein Backup der alten Dateien machen bevor sie ersetzt werden! Mit FHEM 5.7 kann ich gar nicht testen, ob es zu Problemen kommt.
Außerdem natürlich den letzten offiziellen Stand der Firmware bereit halten, falls es unerwünscht läuft!

[linuzer]

Hallo Ansgar und alle anderen fleißigen Entwickler hier,

ich bin in einem anderen thread darauf  hingewiesen worden, diese culfw mit den Timinganpassungen zu probieren, um meine pairing-Probleme zu lösen. Das würde ich auch gerne ausprobieren, bin aber etwas verwirrt, von wo ich jetzt alle relevanten Dateien zusammen bekomme und wie genau ich die Firmware flashen muss.
Ich habe die Anweisungen in diesem Thread befolgt, was aber leider nicht geklappt hat. Ausserdem kenne ich diesen (CUL_am_Raspberry_Pi_flashen) Wiki-Artikel, mit dem ich bereits die a-culfw von sourceforge installiert habe.

Wie muss ich jetzt vorgehen, um diese Timing-Firmware zu installieren?
Sorry, wenn die Frage sehr newbie-haft klingt, aber ich würde mich sehr über einen Tipp freuen!

Edit:
Ich glaube, ich habe es jetzt selbst geschafft, mein CUL zeigt mir das Reading:

Code Auswählen Erweitern

VERSION    V 99.78 CUL868
Ist es das, was er zeigen sollte?
Die anderen Dateien habe ich im FHEM-Verzeichnis ersetzt... Aber sehe ich das richtig, dass die bei einem Fhem-Update wieder überschrieben werden?

Viele Grüße,
linuzer

[noansi]

Hallo Linuzer,

Ich glaube, ich habe es jetzt selbst geschafft,

ja, hast Du. 

Aber sehe ich das richtig, dass die bei einem Fhem-Update wieder überschrieben werden?

Das siehst Du richtig, leider.

Daher musst Du das mit dem Kopieren nach jedem FHEM-Update wiederholen und es kann natürlich auch passieren, das meine *,pm Varianten mit der jeweils aktuellen FHEM Version nicht mehr harmonieren.
Update habe ich schon lange nicht mehr benutzt, da ich solche Überraschungen nicht gebrauchen kann.

Gruß, Ansgar.