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

[Mr. P]

Das siehst Du richtig, leider.

Naja... seht euch doch mal in der commandref das Attribut:

Code Auswählen Erweitern

exclude_from_update an. Ich glaube, das könnte euch gefallen.

[noansi]

Hallo Mr. P,

danke für den Hinweis! Die Funktionsvielfalt von FHEM ist doch immer wieder überwältigend. 

Gruß, Ansgar.

[Mr. P]

Hej Ansgar,

bin ebenfalls immer wieder überrascht.

[Hans5546]

Hallo Fritz und Testwillige,

ich habe mal aus dem TRUNK 499 nanoCUL genommen und angepasst, so dass es mit meinen Änderungen compilierbar ist. Mangels Hardware ...

Gruß, Ansgar.

Hallo Ansgar!

Ich habe die oben genannte Firmware CUL_V3_99_75_3 auf meinen NanoCul mit 433 Mhz-Modul geflasht. Sie läuft auch prima und empfängt in meiner CCU2 mit CuxD auf die WS2000-Sensoren mir Protokoll 1.1

Nun habe ich das Problem, dass ich an einem entfernteren Standort ein Max-Cube mit a-culw werkelt. Dort habe ich ebenfalls ein 433 Mhz-Modul eingelötet und ihn auf 433 Mhz konfiguriert - er läuft, aber empfängt nur WS2000-Sensoren mit Protokoll 1.2

Ich würde nun gerne Deine angepasste asksin.c in die a-culw integrieren (wäre das die einzig nötige Änderung?), um auch dort die alten Sensoren zu empfangen. Wie zu erwarten war, funktioniert das aber nicht so einfach... Und der Quelltext ist doch einfach zu komplex, um ihn zu überschauen.
Hast Du eine Idee, wie ich das dort integrieren kann? Kompilieren der ARM-Firmware läuft problemlos (nach ewigem Ausprobieren...)

Vielen Dank!

[noansi]

Hallo Hans,

bezüglich

WS2000-Sensoren mit Protokoll 1.1

bist Du mit asksin.c an der falschen Baustelle. asksin.c betrifft nur Timestamp für HM.

WS2000 Sensorempfang steckt in rf_receive.c. Und dort suchst Du nach HAS_NO_WS2000_V1_1_SUPPORT, um die Ergänzungen bezüglich 1.1 Protokoll zu finden. Problem war die "unvollständige" Checksumme im Vergleich zu 1.2. Das musst Du sinngemäß in die a-culfw ergänzen.

Im Prinzip würde es zur Vereinfachung auch reichen, statt der Checksumme z.B. eine 0 zu ergänzen, da  14_CUL_WS.pm die Checksumme nicht prüft, aber auf die korrekte Zahl der Nibbles prüft.

Gruß, Ansgar.

[Hans5546]

Hallo Ansgar,

einfach den entsprechenden Bereich reinkopieren klappt (natürlich) nicht... und entsprechend umschreiben, damit es zum Rest der rf_receive.c vom a-culw passt, kann ich leider nicht

Ich nehme nicht an, dass Du dafür Zeit und Lust hast, oder? Im Gegenzug könnte ich nur anbieten, die Firmware dann für den Max Cube zu kompilieren und zum Download zur Verfügung zu stellen... Wobei der Anwendungsfall "433 Mhz Cuno aus Max Cube" mit "WS2000 Protokoll 1.1" schon recht exotisch sein dürfte

EDIT um 20:57: Hallo nochmal,
meine Alternative, an der ich gerade am Basteln bin, ist ein per ser2net angebundener nanoCUL an einem WRT54GL-Router mit DD-WRT drauf.
Im CuxD (würde ebenso in FHEM gehen, da definiert wie ein CUNO) wird der Cul auch schon erkannt und er reagiert auf Terminal-Befehle, ich habe allerdings noch kein Funkmodul angeschlossen, das mache ich gleich mal.
Ist zwar wesentlich größer als ein MaxCube @ 433Mhz aber mittels des WRT54GLs könnte ich den nanoCUL sogar per WLAN ins Netzwerk einbinden

EDIT 2: Der WRT54GL hat übrigens zwei serielle Schnittstellen. Man könnte also parallel auch noch einen 868Mhz Cul anschließen oder dergleichen.

EDIT 3: So, mein "Selbstbau CUNO" mit Deiner auf einen nanoCUL geflashten Firmware läuft und empfängt fleißig 433 Mhz Signale - und das im Netzwerk mit einem per WLAN angebundenen WRT54GL Super, der wird morgen in Betrieb genommen und ich kann hoffentlich alle "alten" Sensoren empfangen

[noansi]

Hallo Hans,

einfach den entsprechenden Bereich reinkopieren klappt (natürlich) nicht... und entsprechend umschreiben, damit es zum Rest der rf_receive.c vom a-culw passt, kann ich leider nicht

Das war das mit dem "sinngemäß". Ich hatte da noch einiges mehr geändert. U.A. erinnere mich auch noch an die Anzahl der Nibbles, die sich je nach Sensortyp (nicht Protokollversion) unterscheidet. Das muss auch angepasst werden. Die Checksummenberechnung hatte ich auch angepackt. Das ist leider mehr als ein bischen Arbeit an der A-CULFW, zumal man jeweils intensiv über die Funktion grübeln muss, da die Kommentare im Quelltext schwach sind.

Aber wie ich sehe, arbeitest Du an einer schneller umzusetzenden Alternativlösung.

Gruß, Ansgar.

[Pythonf]

Wäre es eigentlich möglich, diese Änderungen in die a-culfw einzubauen?

Grüße
Fabian

[noansi]

Hallo Fabian,

Wäre es eigentlich möglich, diese Änderungen in die a-culfw einzubauen?

Wie schon angedeutet, mit Hirnschmalz und einiger Zeit (die ich derzeit leider nicht habe) sicherlich.

Ich sehe die Frage allerdings ohnehin eher im a-culfw thread.

Der Quellcode steht ja für beide Varianten zur Verfügung, um sich Anregungen dafür zu holen.
Timestamp ist für HM und damit für viele interessant.
1.1 Protokoll Support für alte ELV Wetterstationssensoren für weniger User, ebenso wie Wind, Helligkeit und Regen für alte WS2000 Wetterstationen in 1.1 oder 1.2 Protokoll. Der Kunststoff hält leider nicht ewig an der Sonne.


Gruß, Ansgar.

[bjoernh]

Hallo Fabian,

Wie schon angedeutet, mit Hirnschmalz und einiger Zeit (die ich derzeit leider nicht habe) sicherlich.

Ich sehe die Frage allerdings ohnehin eher im a-culfw thread.

Der Quellcode steht ja für beide Varianten zur Verfügung, um sich Anregungen dafür zu holen.
Timestamp ist für HM und damit für viele interessant.
1.1 Protokoll Support für alte ELV Wetterstationssensoren für weniger User, ebenso wie Wind, Helligkeit und Regen für alte WS2000 Wetterstationen in 1.1 oder 1.2 Protokoll. Der Kunststoff hält leider nicht ewig an der Sonne.


Gruß, Ansgar.

Hi, 
ich kann euch auch gerne Zugriff auf das Repository geben,  dann könnt ihr es einbauen. Gerne unterstütze ich euch auch dabei.  Momentan habe ich leider nicht viel Zeit um mich darum zu kümmern.
Wie gesagt,  wenn Interesse besteht,  dann bitte kurz melden.
Gruß Björn

[Pythonf]

Welches ist nun eigentlich die aktuelle Version? Die aus Post #116/117 oder aus diesem Thread https://forum.fhem.de/index.php/topic,31421.msg239101.html#msg239101? Und da die 00_CUL.pm abgeändert wird gibt es irgendwelche Nachteile bzw. in wie weit werden aktuelle Updates mit einbezogen?

#EDIT
Und wie muss ich vorgehen, wenn ich einen nanoCUL flashen will?
Hab einen Fehler, wenn ich versuche die FW zu kompilieren:

Code Auswählen Erweitern

makefile:338: recipe for target '../../clib/rf_asksin.o' failed


[noansi]

Hallo Pythonf,

Welches ist nun eigentlich die aktuelle Version? Die aus Post #116/117

Du hast die neueste von mir veröffentlichte Version gefunden.

Und da die 00_CUL.pm abgeändert wird gibt es irgendwelche Nachteile bzw. in wie weit werden aktuelle Updates mit einbezogen?

Wie dort im Post steht, ich arbeite auf dem älteren FHEM Stand und kann es daher nicht testen, ob Nebenwirkungen mit dem aktuellen FHEM Stand auftreten.
Also mit Backup der Dateien arbeiten, um ggf. den Rückweg zu erleichtern oder auftretende Probleme im perl Code aufspüren und beheben. (Und bitte hier mitteilen.  )

Und wie muss ich vorgehen, wenn ich einen nanoCUL flashen will?

Ich kann nur CUL, SCC, COC und CUNO2 testen, respektive die Hardware anschauen.

Bei nanoCUL musst Du einen Blick in die board.h werfen und nach

#define SPI_CC1101_READ_SPECIAL_PORT  PORTB
#define SPI_CC1101_READ_SPECIAL_DDR   DDRB
// #define SPI_CC1101_READ_SPECIAL_PIN   6     // we missuse this unused (has to be checked!) pin as fast signaling bit for special cc1101_read_buf

schauen. (Der Compilerfehler vor der von Dir dargestellten Fehlerausgabe gibt den Hinweis).

Du musst also auf Deine nanoCul Hardware schauen und dort einen freien Pin auf PortB (vgl. die vorherigen beiden Zeilen) des Atmels finden. Dann kannst Du den Kommentar aus obiger Zeile entfernen und die entsprechende I/O Pin (Bit) Nummer statt der 6 eintragen. Ich habe die Hardware nicht und kann das daher nicht machen.
Sollte es mit PortB nicht gehen, weil voll genutzt, kannst Du auch einen anderen Port nehmen und in der board.h entsprechend anpassen (Port+DDR) und dessen freien Pin eintragen.

Diesen ungenutzen Pin benutze ich im Code dann als schnelles, speichersparendes Flag (dank der Atmel Bitmanipulationsbefehle für den unteren I/O Bereich). Speicher ist je nach Atmel knapp und Flashspeicher je nach Hardware leider auch, deswegen + Geschwindigkeitsvorteil bin ich auf diese für Dich leider unbequeme Idee gekommen.

Gruß, Ansgar.

[MadMax-FHEM]

Hallo,

vielleicht/hoffentlich bin ich hier richtig...

Habe mich schon ein wenig durch's Forum gewühlt.

Habe mitbekommen, dass es wohl (ab und an bzw. mit gewissen HM-Komponenten) Timingprobleme mit CUL gibt.

Habe bereits hier:

https://forum.fhem.de/index.php/topic,53367.0.html

und hier versucht eine Antwort/Lösung zu bekommen:

https://forum.fhem.de/index.php/topic,30275.msg447944.html#msg447944

Habe mir dann diesen Thread durchgelesen und mir folgendes mal runtergeladen:

https://forum.fhem.de/index.php/topic,24436.msg397787.html#msg397787

"culfw-code-459-trunk_lufa_rf_cr_sd_78_2.zip "

Habe einen NanoCUL868 Einsatz soll Homematic sein.

Wenn ich diesen dann baue und flashe habe ich dann eine cul-fw mit Timingkorrekturen für HM, die dann mit 00_CUL.pm zusammenarbeitet??

Vielen Dank!!

Gruß, Joachim

[noansi]

Hallo Joachim,

Wenn ich diesen dann baue und flashe habe ich dann eine cul-fw mit Timingkorrekturen für HM, die dann mit 00_CUL.pm zusammenarbeitet??

Lies bitte auch mal mehr in diesem Thread. Dann siehst Du z.B., dass Du ein Update im folgenden Beitrag übersehen hast.

Bei NanoCUL muss Dir noch klar sein, welchen Atmel Prozessor Du hast und an welchen Pins was angelötet ist.
Dann kannst Du die Firmware entsprechend konfigurieren (board.h, makefile, nanoCUL.c), compilieren und dann flashen.
Ich fürchte, da musst Du noch was lesen und experimentieren, um zum Ziel zu kommen. Macht aber auch Spaß.

Gruß,

Ansgar.

[MadMax-FHEM]

Hallo Ansgar,

vielen Dank für die Antwort...

Hab noch mal ab meiner Verlinkung geschaut aber konnte keine neuere Version (als culfw-code-459-trunk_lufa_rf_cr_sd_78_2.zip) entdecken...

Bin wohl zu doof...

Nur eine neuere Version von 00_CUL.pm

Hab noch mal ein wenig gelesen und es wird erwähnt, dass askin.c nur HM betrifft.

Andersrum gefragt: wenn ich die neueste von dir (glaube ich waren die Anpassungen!?) asksin.c in die runtergeladenen Sourcen (neueste Version der "standard cul-fw") austausche habe ich dann alles was ich für Homematic timing brauche?

Also die aktuell laufende Version habe ich selbst gebaut und geflasht.
Läuft soweit auch prima.
Nur mit manchen Komponenten (optische Fenstersensoren und der Klingelsensor) gibt es Probleme die (so wie ich es gefunden hab) wohl mit dem Timing zu tun haben...

Entschuldige, wenn ich (wahrscheinlich wirklich) dumm frage und es nicht finden kann...
Aber ich habe mittlerweile so viel in so vielen Threads darüber gelesen aber irgendwie hab ich nicht herausfinden können was/wo nun die aktuellste Version für die HM-Timing Problematik zu finden ist...

Gruß, Joachim