FHEMduino

[Bennemannc]

Hallo,

eigentlich gibt es ja schon zwei Decoder in Fhem - der Oregon aus dem RFXTRX und der Weather aus dem TRX Bereich. Vielleicht könnte man Teile daraus nutzen. Für einen Sketch habe ich ein Ino File gefunden, was sie Sensoren ausließt. Ein Vergleich mit einer Protokollbeschreibung passte Aussöhnung weit. Ich habe nur noch keine Ahnung, wie ich die Daten nach Fhem bekomme.

Gruß Christoph

[Olly]

Hallo,

mit dem neuesten Sketch (der mit DCF77 Unterstützung) funktionieren meine 2 WS0002 von Logilink nicht mehr. Hab IS_WS0002 im Sketch auf true gesetzt. Auch wenn ich DEBUG setze tut sich da nix. Da ist irgendwo der Wurm drin. Mit dem Sketch vom 13.06. funktioniert es noch.
Kann das noch wer nachvollziehen??

Gruß

     Olly

[JoWiemann]

Hallo,

mit dem neuesten Sketch (der mit DCF77 Unterstützung) funktionieren meine 2 WS0002 von Logilink nicht mehr... Mit dem Sketch vom 13.06. funktioniert es noch.
Kann das noch wer nachvollziehen??

Gruß

     Olly

Hallo Olly,

Ich habe nicht mehr getestet, ob die Reduzierung der Duration-Time von 5000 auf 2500 kompatibel ist. Bitte setzt doch die Parameter wieder auf 5000 und 200 zurück. Ist im Code Kommentiert. Wenn es das nicht ist, dann setzt doch bitte IS_DCF77 auf false. Dann scheint durch ein fehlendes DCF77-Modul der freie D3 des Arduino zu stören. Bei mir läuft der Sketch mit DCF77 - allerdings mit Duration-Time 5000 und Timnigsoffset von 200 - seit gestern Nachmittag einwandfrei.

Ich habe mal einen neuen Sketch angehängt, in dem ich die Duration-Time und den Offset in #defines gepackt hab.

Grüße Jörg

[JoWiemann]

Hallo,

eigentlich gibt es ja schon zwei Decoder in Fhem - ... Sketch habe ich ein Ino File gefunden, was sie Sensoren ausließt. Ein Vergleich mit einer Protokollbeschreibung passte Aussöhnung weit. Ich habe nur noch keine Ahnung, wie ich die Daten nach Fhem bekomme.

Gruß Christoph

Hallo Christoph,

würdest Du den Sketch einmal posten. Ich würde dann mal schaun, wie ich den implementiert bekomme.

Grüße Jörg

[JoWiemann]

Hi,

... Wozu könnte macht das DCF77 Signal nun sinnvoll verwenden.
Ich weiss, dass der Arduino die Zeit an FHEM überträgt. Wird dann damit die Uhr des FHEM System gestellt?

Grüße Sidey

Hallo Sidey,

das ist jetzt erst einmal eine Spielerei. Es werden nur die Daten nach FHEM übergeben, ansonsten passiert erst einmal nichts.

Grüße Jörg

[Olly]

Hallo Olly,

Ich habe nicht mehr getestet, ob die Reduzierung der Duration-Time von 5000 auf 2500 kompatibel ist. Bitte setzt doch die Parameter wieder auf 5000 und 200 zurück. Ist im Code Kommentiert. Wenn es das nicht ist, dann setzt doch bitte IS_DCF77 auf false. Dann scheint durch ein fehlendes DCF77-Modul der freie D3 des Arduino zu stören. Bei mir läuft der Sketch mit DCF77 - allerdings mit Duration-Time 5000 und Timnigsoffset von 200 - seit gestern Nachmittag einwandfrei.

Ich habe mal einen neuen Sketch angehängt, in dem ich die Duration-Time und den Offset in #defines gepackt hab.

Grüße Jörg

Hallo Jörg,

werde den neuen Sketch heute Abend mal ausprobieren. Das DCF77 hatte ich schon längst disabled, da ich das nicht nutze.
Übrigens, gute Idee mit dem Empfänger aus der LogiLink Basisstation. Der funktioniert besser als alles andere was ich bisher hatte. Hab eine Basis, die nicht initialisiert, die hab ich geschlachtet .

Gruß

     Olly

[Olly]

Sorry Doppelpost

[Olly]

Sorry Doppelpost

[Bennemannc]

Hallo Jörg,

hier kommen die Daten - ich weiß nicht genau, ob das der Decoder ist, den ich zuletzt getestet habe. Aber als Vorlage sollte der passen. Zudem noch eine Protokollbeschreibung, die ich im Netz gefunden habe.

Gruß Christoph

[Sidey]

Hi,

Ich habe mir mal auf die schnelle den OREGON.pm Teil angesehen.
So wie ich das interpretiere, wird hier das os Protokoll ausgewertet.

Damit fhemduino damit verwendet werden kann, müsste wohl noch eine Schnittstelle her, die das, was von fhemduino kommt, im richtigen Format an die OREGON.pm übergibt. Derzeit scheint die mir auf den rfxtrx Empfänger ausgelegt zu sein.

Der Arduino müsste das übrrmittelte Signal als OS Protokoll erkennen und im passenden Format ( weiss noch nicht wie das aussieht) an fhem übergeben.

Das erkennen der verschiedenen OS Protokolle sollte mit Hifle der Protokoll Beschreibung und den libarys recht einfach möglich sein. Sobald die Präambel erkannt wurde, können wir recht sicher auch das Protokoll bestimmen.


Der angehängte ookDekoder vom vorherigen Post hat einen Fehler. Zumindest  beim V2 Protokoll erwartet dieser eine Präambel von 32 Bit. Es gibt aber Sender die weniger senden.
Dazu am besten den code nutzen, der in dem gestrigen Post von mir verlinkt ist. Die Seite ist zwar auf französisch, aber dem code ist das egal.

Eventuell kann ich das auch die Tage mal testen.

Grüße Sidey

[JoWiemann]

Hallo,

ich habe jetzt mal im Sketch das füllen des Timings-Array für Duration 5000 und Intervall 200 sowie für Duration 2500 und Intervall 100 in zwei eigene Funktionen ausgelagert. Könnt ihr mal ausprobieren, ob das so funktioniert. Danke Euch


Edit. Sorry, habe bei den #defines nicht aufgepasst. Jetzt die beim mir getestete Version

Jörg

[pejonp]

Hi,

Ich habe mir mal auf die schnelle den OREGON.pm Teil angesehen.
So wie ich das interpretiere, wird hier das os Protokoll ausgewertet.....

Hallo,
Vieleicht könnt hier ja mal bei LaCross nachsehen ob dort etwas passt. Dort ist ein Sensor WT440XH eingebunden worden. Als Vorlage habe ich ein Protokoll von UMP genommen.
http://wiki.nethome.nu/doku.php/upmprotocol wurde es so beschrieben passt aber nicht ganz für den WT440XH.

Hier kommt der link ins forum (hoffe ich) http://forum.fhem.de/index.php/topic,14786.msg172449.html#msg172449
Viel Glück Jörg

[Sidey]

Hi,

ich habe den Sketch von (http://connectingstuff.net/blog/decodage-des-protocoles-oregon-scientific-sur-arduino-2/) genommen und ausprobiert.

Damit werden jetzt erst mal nur Sensoren mit dem OSV2 Protokoll erkannt. Eine Erweiterung auf andere Protokolle ist möglich.
Dazu müsste Code von
Ich habe einen mit Version 2.2. Einige Versuche habe ich unternommen, aber das brachte jetzt noch nicht den entscheidenen Vorteil.

Probiert doch einfach mal aus, was ihr damit emfpangt und ob die Werte stimmen.


Eventuell müsst ihr den PIN anpassen, an dem der Emfänger angeschlossen ist. Bei mir ist es Pin 5, da ich einen ProMicro verwende. Bei euch vielleicht Pin 3

Diese beiden Zeilen müssen ggf. angepasst werden:

Code Auswählen Erweitern


void setup ()
{
  pinMode(5, INPUT);
  attachInterrupt(0, ext_int_1, CHANGE);


Ich habe es bisher noch nicht geschafft wirklich passende Werte zu empfangen. Vielleicht habt ihr ja mehr Glück.

Grüße Sidey

[mick6300]

Hallo,

ich habe jetzt mal im Sketch das füllen des Timings-Array für Duration 5000 und Intervall 200 sowie für Duration 2500 und Intervall 100 in zwei eigene Funktionen ausgelagert. Könnt ihr mal ausprobieren, ob das so funktioniert. Danke Euch


Edit. Sorry, habe bei den #defines nicht aufgepasst. Jetzt die beim mir getestete Version

Jörg

Hallo Jörg,
vielen Dank für Deine Hilfe. Ich habe das Modul gerade getestet. Ach mir war aufgefallen, dass mein altes Sendemodul (5000) mit meinen Änderungen nicht mehr funktioniert. Mit Deinem Modul empfange ich jedoch nun nicht mehr das Protokoll des ALDI-Senders (2500). Auch ich hatte den Gedanken es in zwei Funktionen zu trennen, bin allerdings auch noch nicht weiter gekommen.

Hier noch eine weitere Frage: Im Floorplan bekomme ich alle Aktoren von FHEM angezeigt, bis auf die von FMDUINO. Habe ich einen Eintrag in der fhem.cfg vergessen?

Gruß
Michael

[Olly]

Hallo,

ich habe jetzt mal im Sketch das füllen des Timings-Array für Duration 5000 und Intervall 200 sowie für Duration 2500 und Intervall 100 in zwei eigene Funktionen ausgelagert. Könnt ihr mal ausprobieren, ob das so funktioniert. Danke Euch


Edit. Sorry, habe bei den #defines nicht aufgepasst. Jetzt die beim mir getestete Version

Jörg

Hallo Jörg,

mit diesem angepassten Sketch funktionieren die WS0002 bei mir jetzt wieder.
Die geänderte DURATION_TIME war mir bei Vergleichen gar nicht aufgefallen.

Danke und Gruß

      Olly