Autor Thema: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39  (Gelesen 264655 mal)

Offline Mr. P

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 988
Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
« Antwort #120 am: 02 März 2016, 13:26:12 »
Das siehst Du richtig, leider.
Naja... seht euch doch mal in der commandref das Attribut: exclude_from_update an. Ich glaube, das könnte euch gefallen. ;-)
Greetz,
   Mr. P

Offline noansi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1310
Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
« Antwort #121 am: 02 März 2016, 21:17:32 »
Hallo Mr. P,

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

Gruß, Ansgar.

Offline Mr. P

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 988
Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
« Antwort #122 am: 08 März 2016, 08:52:02 »
Hej Ansgar,

bin ebenfalls immer wieder überrascht. :-)
Greetz,
   Mr. P

Hans5546

  • Gast
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!

Offline noansi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1310
Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
« Antwort #124 am: 06 April 2016, 19:50:54 »
Hallo Hans,

bezüglich

Zitat
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.
« Letzte Änderung: 06 April 2016, 20:30:02 von noansi »

Hans5546

  • Gast
Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
« Antwort #125 am: 08 April 2016, 14:27:50 »
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 :-)
« Letzte Änderung: 08 April 2016, 23:08:43 von Hans5546 »

Offline noansi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1310
Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
« Antwort #126 am: 11 April 2016, 18:52:54 »
Hallo Hans,

Zitat
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.

Offline Pythonf

  • Full Member
  • ***
  • Beiträge: 478
Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
« Antwort #127 am: 18 April 2016, 14:11:13 »
Wäre es eigentlich möglich, diese Änderungen in die a-culfw einzubauen?

Grüße
Fabian

Offline noansi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1310
Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
« Antwort #128 am: 18 April 2016, 21:52:33 »
Hallo Fabian,


Zitat
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.

Offline bjoernh

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 765
Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
« Antwort #129 am: 18 April 2016, 21:58:25 »
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

Offline Pythonf

  • Full Member
  • ***
  • Beiträge: 478
Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
« Antwort #130 am: 20 April 2016, 16:10:37 »
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:
makefile:338: recipe for target '../../clib/rf_asksin.o' failed
« Letzte Änderung: 20 April 2016, 17:25:31 von Pythonf »

Offline noansi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1310
Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
« Antwort #131 am: 20 April 2016, 22:57:46 »
Hallo Pythonf,

Zitat
Welches ist nun eigentlich die aktuelle Version? Die aus Post #116/117
Du hast die neueste von mir veröffentlichte Version gefunden.

Zitat
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.  :) )

Zitat
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

Zitat
#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.

Online MadMax-FHEM

  • Hero Member
  • *****
  • Beiträge: 10981
  • NIVEAu ist keine Creme...
Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
« Antwort #132 am: 15 Mai 2016, 00:33:57 »
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
FHEM PI3B+ Buster: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)
FHEM PI3 RaspiOS (Test)

Offline noansi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1310
Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
« Antwort #133 am: 16 Mai 2016, 18:50:53 »
Hallo Joachim,

Zitat
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.

Online MadMax-FHEM

  • Hero Member
  • *****
  • Beiträge: 10981
  • NIVEAu ist keine Creme...
Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
« Antwort #134 am: 16 Mai 2016, 19:58:27 »
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
FHEM PI3B+ Buster: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)
FHEM PI3 RaspiOS (Test)

 

decade-submarginal