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

[noansi]

Hallo Rudolf,

danke für den Wink, wie ich einen Forumsbeitrag zu einer Änderung finden kann.

Ok, ich denke ich hab's verstanden.
- Vom EnOcean Modul kommt 55usw. (gut das der Sync keinen Buchstaben enthält, ein Kennbuchstabe hätte aber besser in's System gepasst)
  dabei wird bei jedem SCC ein * ergänzt, wie gehabt. Klappt also. Die 5 ist also Kennung und zugleich Datenanteil. Wenn sie auch nicht als Kennung genutzt wird.
- an das EnOcean Modul wird % als Kennbuchstabe gesendet.
  mit den SCCs werden weiter * vorrangestellt,wie gehabt

richtig?

(Von den 57600baud bin ich nicht so begeistert. Mit gleichzeitigem SlowRF Empfang wird die Luft da schon dünn bis zum Datenverlust auf der seriellen Schnitsstelle, bzw. auch die Zeit um die EnOcean Daten nach unten weiter zu reichen. Also Klotzen mit den Puffern, statt Kleckern, wenn größere EnOcean Pakete hin und her sollen.)

So lange ich das nicht bei mir in die Firmware einbaue, muss ich es also eigentlich nicht in TSSTACKED berücksichtigen, da ich nur '*' zu sehen bekomme.   Aber nu isses ja schon quasi drin.

Gruß und danke, Ansgar.

[rudolfkoenig]

Die 5 ist also Kennung und zugleich Datenanteil

Ich meine nicht. Wenn das SCC als TCM gekennzeichnet ist, dann ist der Prefix %, sonst *, in beide Richtungen. Im TCM Fall wird beim Schreiben Binaer in Hex gewandelt, und beim Lesen umgekehrt. Achtung: das Ganze ist im TCM Fall verschachtelter als man denkt, es laeuft ueber DevIo als IODev, mit definierten IOReadFn/IOWriteFn. Wie gesagt: ohne Testen will ich es nicht anfassen

[noansi]

Hallo Rudolf,

Wenn das SCC als TCM gekennzeichnet ist, dann ist der Prefix %, sonst *, in beide Richtungen.

Dem Code nach zumindest nicht.
Im SCC vor dem TCM Hardware Modul wird nur bei einem empfangenen '%' UART1 auf 57600 umgestellt und gesendet, was dann kommt nach Umwandlung von HEX in Binär.
Über UART1 empfangene Daten werden von binaer nach HEX umkodiert und dann Richtung FHEM geschickt. Von einem % habe ich da nichts gesehen. Statt dessen wird die 5 nicht weggefiltert beim DelPrefix (der Match hat mich erst mal wieder genarrt).
Ausschläusen musst Du über das IODEV, % wird da nicht geparst und somit auch nicht über den Dispatcher an das passende FHEM Modul weiter geleitet. So mein Verständnis.

Ich verstehe, dass Du es nicht unnötig anpacken möchtest... tricky, genau wie STACKABLE... 

Gruß, Ansgar.

[chris1284]

ist die version in « Antwort #266 am: 27 November 2016, 18:19:57 » immer noch die neuste? (komische angewohnheit sowas nicht im erföffnungspost einzubauen sondern mitten in einer von xxxxxxx seiten, gut hier ist wenigstens ein link im post 1   )

wenn ja, wäre es möglich den culCUBE /CUBe als unterstütztes device aufzunehmen oder gleich alle cul-derrivate wie es die aculfw macht?
https://github.com/heliflieger/a-culfw/tree/master/culfw/Devices

ich habe einen cube der ausschließlich hm macht und da wäre die fw wohl die bessere wahl

[noansi]

Hallo Chris,

hier https://forum.fhem.de/index.php/topic,24436.msg540872/topicseen.html#msg540872 hatte ich darauf schon mal geantwortet.

Code Auswählen Erweitern

  AT91C_BASE_TC1->TC_CMR = AT91C_TC_CLKS_TIMER_DIV4_CLOCK | AT91C_TC_CPCTRG;  // Timer1: 2,666us = 48MHz/128

ließt sich da leider recht kontraproduktiv.

D.h. intesiver check an allen code Teilen, die mit den 16-bit Timer 1 Timing machen bezüglich Überlauf und ggf. Umgehung.

Timer 1 muss auf 8µs laufen, wie beim CUL, um relativ schnell zum Ziel zu kommen. Geht das mit dem ARM im CUBE?

Ich habe nicht die Hardware, um damit denn auch zu testen. Geschweigedenn Ahnung vom ARM.

Gruß, Ansgar.

[Bastel-Frank]

Hallo Ansgar,

ich habe versucht, die Firmware eines Devices OverTheAir (OTA) upzudaten. Das OTA-Tool fragt leider die Firmware-Version ab, und bricht dann den Firmware-Prozess ab, da die Version zu klein zu.

Code Auswählen Erweitern

Opening culfw-device at path /dev/ttyACM0 with speed 38400
Requesting firmware version
culfw-device firmware version: 0.05

This version does _not_ support firmware upgrade mode, you need at least 1.58!


Was kann man da machen?

Viele Grüße
Frank

[noansi]

Hallo Frank,

Was kann man da machen?

im Quellcode der firmware kannst Du

#define VERSION_1               00
#define VERSION_2               06
#define VERSION                 "0.06"

die Versionsnummer ändern, neu compilieren und auf den CUL flashen.

Bei HM-Devices in fhem gibt es:

Code Auswählen Erweitern

set  fwUpdate [onlyEnterBootLoader] <filename> [<waitTime>]

Da ich bisher keine Testrückmeldung zum Firmwareupdate in den letzten Versionen bekommen habe, bist Du dabei alpha-Tester.
Die Firmware unterstützt die Umschaltung in den FUP Modus.
Ich habe allerdings selbst kein OTA-Update fähiges device, um es testen zu können.

In jedem Fall musst Du abwarten, bis die credits in CUL aufgeladen sind (1800 ist max.), damit sie während es Updates nicht ausgehen.

Gruß, Ansgar.

[Bastel-Frank]

Hallo Ansgar,

wie kann man die Firmware compilieren?

Ein make im /.../DEVICES/CUL Verzeichnis bringt folgende Fehlermeldung:

Code Auswählen Erweitern

Cleaning project:
Compiling C: ../../clib/Descriptors.c
/bin/sh: 1: avr-gcc: not found
makefile:230: recipe for target '../../clib/Descriptors.o' failed
make[1]: *** [../../clib/Descriptors.o] Error 127


Viele Grüße
Frank

[noansi]

Hallo Frank,

hast Du es erst mal mit dem FHEM Firmwareupdate über set fwUpdate für das device probiert?
Das wäre der erste Versuch. Da ist mir keine Versionsabfrage aufgefallen.

wie kann man die Firmware compilieren?

/bin/sh: 1: avr-gcc: not found

Du musst erst mal mit aptitude avr-gcc nebst libs installieren. Der Compiler wird nicht gefunden.

Gruß, Ansgar.

[Bastel-Frank]

ok, übersetzen geht jetzt. Unter Ubuntu muss man folgende Pakete installieren:

Code Auswählen Erweitern

apt-get install gcc-avr avr-libc binutils-avr

Mit fwUpdate habe ich noch Probleme, da die betreffende eq3-Datei leider einen CRC-Fehler hat.

[noansi]

Hallo Frank,

noch ein Hinweis. Wenn Du bei der Firmware die Version hoch setzt, dann musst Du bei der aktuellen 00_TSCUL.pm auch oben

my $reqTSCulFWmax        = 0.06;                           # required max. tscul firmware version

anpassen, wenn Du nicht zurück flashen möchtest.

Sonst meckert 00_TSCUL.pm später die Firmware an und will damit nicht zusammen arbeiten.

Gruß, Ansgar.

[Bastel-Frank]

Hallo Ansgar,

nochmal eine Frage. Wie stelle ich mit den Parametern z.B. die Version 1.66 ein?

Code Auswählen Erweitern

#define VERSION_1               00
#define VERSION_2               06
#define VERSION                 "0.06"

Viele Grüße
Frank

[theophilou85]

Hallo Ansgar

Habe jetzt deine Firmware noch weiter getestet. Homematic läuft einwandfrei, aber die Deckenlampe zickt manchmal:

Code Auswählen Erweitern

2017.01.16 19:01:07 2: wz0_cul00 IT_set: wz0_del00_sch00 off
2017.01.16 19:01:12 2: IT IODev device didn't answer is command correctly:   raw => AFF130666B57E0109C4B11200000126043E80
2017.01.16 19:01:12 2: wz0_cul00 IT_set: wz0_del00_sch01 off
2017.01.16 19:01:17 2: IT IODev device didn't answer is command correctly:   raw => is00100000100001100110010110001000
2017.01.16 19:01:18 3: wz0_cul00: Unknown code is00100000100001100110010110001001, help me!
2017.01.16 19:01:19 3: TSCUL_XmitDlyHM:  wz0_cul00  id:4E9763 dDly:107 toms:75
2017.01.16 19:01:20 1: TSCUL_ParseTsHM wz0_cul00 HM repeat failed sending to 26043E/wz0_the00: AFF200666C1BB000CC5A01100000126043E86
2017.01.16 19:01:56 3: TSCUL_XmitDlyHM:  wz0_cul00  id:26BDD2 dDly:43 toms:74

Code Auswählen Erweitern

define wz0_del00_sch00 IT 00100000100001100110010110 0 1000
attr wz0_del00_sch00 IODev wz0_cul00
attr wz0_del00_sch00 alias Licht
attr wz0_del00_sch00 group [AC] Deckenleuchten
attr wz0_del00_sch00 room X_Geräte,Deckenleuchten

define wz0_del00_sch01 IT 00100000100001100110010110 0 1001
attr wz0_del00_sch01 IODev wz0_cul00
attr wz0_del00_sch01 alias Ambiente
attr wz0_del00_sch01 group [AC] Deckenleuchten
attr wz0_del00_sch01 room X_Geräte,Deckenleuchten

Folgende Firmware: CUL_V3 TSCUL_fwcode_00_05_02.hex

[noansi]

Hallo theophilou85,

aber die Deckenlampe zickt manchmal

Schaltet sie richtig, so wie gewünscht?

IT IODev device didn't answer is command correctly:   raw => AFF130666B57E0109C4B11200000126043E80

Das ist Folge des Mischbetriebs. IT gesendet und zufällig gerade HM empfangen. (der HM Empfang ist in diesem Fall sogar verloren, da es nicht weiter geparst wird)
Du hast es so gewollt. 
Lösung: eigener CUL für IT
Aber auch dann können noch andere IT oder SlowRF Daten empfangen werden, so dass das Senden an CUL und Auswerten der ersten Antwort nie richtig funktionieren kann.

2017.01.16 19:01:17 2: IT IODev device didn't answer is command correctly:   raw => is00100000100001100110010110001000
2017.01.16 19:01:18 3: wz0_cul00: Unknown code is00100000100001100110010110001001, help me!

Ich habe das Feedback zum Senden geändert, eben wegen obigen Grund.
Mit dem "is" könnte man das normal Parsen und über den Dispatcher wieder IT zuführen zwecks Auswertung.
Das IT Modul kommt mit diesem geänderten Feedback aber nicht zurecht.
Das werde ich auch nicht ändern, weil das meiner Ansicht nach die sinnvolle Lösung für Mischbetrieb ist. Das IT Modul müßte dahingehend sinnvoll angepasst werden.
Das Feedback ist aber eigentlich so weitgehend Quatsch, weil eh nur das zurück kommt, was zu CUL geschickt wurde. Ob es gesendet wurde geht daraus nicht hervor (und ob die Lampe schaltet sowieso nicht). Nur Probleme bei der seriellen Datenübertragung (z.B. zu kleiner Puffer auf CUL) fallen so auf.

Mit verbose 5 bei Deinen IT devices kannst Du auch loggen, was an CUL raus geht und mit dem vergleichen, was zurück kommt, falls die Lampen nicht richtig schalten.
Die 0, die gegenüber der Definition mehr drin ist, muss so vom IT Modul kommen. Ob das so richtig ist, habe nicht geprüft.

Wenn die Lampen richtig schalten, dann verbose 0 bei den IT devices und im log taucht es nicht mehr auf. (Oder das IT Modul umprogrammieren.)

Gruß, Ansgar.

[theophilou85]

Hallo Ansgar

Bis vor zwei Tagen hat sie noch richtig geschalten. Habe es jetzt mehrfach probiert und sie schaltet nicht mehr, sehr wohl aber alle anderen IT-Devices.
Ich werde auf ein eigenes Device umsteigen, sobald der Tuxradio v4 verfügbar ist, bis dahin, hätte ich mich gerne noch so über Wasser gehalten.

Gibt es ein Workaround für meine Situation?

Unterstützt deine Firmware eigentlich: TRX_LIGHT.pm? Dann könnte ich versuchen den Befehl mal direkt mit AC abzusetzen.