FHEMduino

[Sidey]

Moinsen,
Hatte den Thread einige Tage nicht verfolgt
Den Oregon support hatte ich ja schon vor einigen Wochen angefangen zu entwickeln.

Testet doch bitte mal die aktuellen Versionen aus dem aus dem Trunk( Module und arduino code)

Der Arduino sendet die Daten jetzt so, dass sie im original Oregon.pm Modul, welches bei Fhem dabei ist, verarbeitet werden kann.

Grüße Sidey

[locutus]

Die Module und der Sketch aus dem Trunk sind nicht up to date.
Der neuste Sketch wirft beim Aktivieren des OSV2 Supports Fehlermeldungen aus:

Code Auswählen Erweitern

NewFHEMduino:122: error: expected unqualified-id before 'unsigned'
NewFHEMduino:122: error: expected `)' before 'unsigned'
NewFHEMduino:697: error: expected unqualified-id before 'unsigned'
NewFHEMduino:697: error: expected `)' before 'unsigned'


[Sidey]

Hallo Iocutus,

Was meinst Du mit nicht aktuell?
Im git gibt es meines Erachtens nichts neueres.
Alle Änderungen die da hinterlegt sind, finden sich auch im code wieder, welchen ich eingecheckt habe.

Die anderen Zweige haben aus meiner Sicht auch nichts aktuelles zu bieten.
Mir ist jetzt nicht ganz klar, wo der Fehler kommt, den du da gepostest hast.

Ich habe den Code aus dem Trunk bei mir 1:1 laufen.

Sidey

[JoWiemann]

Hallo Iocutus,

Was meinst Du mit nicht aktuell?
Im git gibt es meines Erachtens nichts neueres.
Alle Änderungen die da hinterlegt sind, finden sich auch im code wieder, welchen ich eingecheckt habe.

Hallo Sidey,

ich habe mittlerweile  2 Funkgongs hinzugenommen und die Dekodierung bei den Wettersensoren, bis auf Oregon, aus dem Sketch nach FHEM in ein zentrales Modul verlagert. Wenn ich Zeit habe werde ich am Sonntag die beiden Sketche wieder im Trunk zusammenführen. Oregon und IT bleibt weiter außen vor, da es hierfür, wie Du schon gepostet hast, bereits FHEM-Module gibt.

Hallo Locutus,

die Fehler beim Compilieren betreffen welchen Sketch. Ich habe die Fehler jedenfalls nicht.

Grüße Jörg

[locutus]

Hallo Jörg,

diesen: http://forum.fhem.de/index.php/topic,17196.msg188232.html#msg188232

Danke!

[JoWiemann]

Hallo Locutus,

hast Du defines aktiviert/deaktiviert anders als im Sketch. Manchmal "spinnt" die Arduino IDE?

Grüße Jörg

[CaptainHook]

Hallo Locutus,

hast Du defines aktiviert/deaktiviert anders als im Sketch. Manchmal "spinnt" die Arduino IDE?

Grüße Jörg

Den Fehler  hatte ich  auch, liegt an der ide 1.5.x und weil das define für osv2 gleich heißt wie die Funktion. Wenn du dir meinen Sketch anschaust wirst du sehen das ich die Funktion umbenannt hatte.

Gruß,
Stephan

[Sidey]

Hey Leute,

Wenn ich das lese dass hier zig verschiedene Sketche entwickelt wetden, dann ist meine Motivation gleich wieder im Keller.
Wir haben doch ein repository, legt eure Modifikationen doch bitte da rein.
Da könnt ihr für experimentelle Änderungen auch eigene Zweige auf machen.
Anschließend hat man es so viel einfacher die Teile zu verbinden.

Ich Blick so jedenfals nicht durch.
Wenn jemand den code aus dem Trunk mal hinsichtlich OSV support testen würde und anschließend feedback gibt würde ich mich freuen. Bislang weiss ich nur, dass es bei mir läuft, aber ich habe etwas spezielle sensoren.

Grüße Sidey

[JoWiemann]

Hallo,

es sind doch gar nicht verschiedene Sketche, sondern verschiedene Schwerpunkte. Hilfreich für uns alle wäre eine Modularisierung, so dass man an einem Modul in Ruhe arbeiten kann.

Ich habe in den letzten Wochen eigentlich nur die Wettersensoren, ohne Oregon, vereinheitlicht und die Entschlüsselung nach FHEM verlagert.

Hinzugekommen sind noch Funkgongs und der IT TX 2/3/4 Wettersensor.

Vorschlag: Lasst uns ein Regelwerk für Module aufstellen und das Ganze umsetzen und auf GitHub abbilden.

Grüße Jörg

[Sidey]

Hi Jörg,

Ja, das sollten wir noch mal genauer festlegen. Was wann wo gespeichert wird.
Es baut leider nicht auf, wenn man 4 Wochen lang im Forum nichts liest, sich ans gut hält und dann der sketch nicht mehr up to date ist.
Hinsichtlich Modularisierung hatte ich ja gesagt, dass ich mich darum kümmere.

Viel vorweisen, außer ein paar Ideen kann ich noch nicht.

- Eine genetische Klasse, welche mit Parametern den Beginn  eines Funksignal erkennt, die 0en und 1en auswertet und am Ende die Daten ubergibt.
Vorher muss aber auch erst der Interrupt und die Verarbeitung abgekoppelt werden. Darüber haben ja auch schon Diskussionen im github geführt. Da gibts prinzipiell einen ersten Prototyp. Der kann aber eigentlich noch nichts.

Die Auswertung der Daten soll über eien ringpuffer laufen, in dem sich alle Decoder einen Zeiger setzen, um nicht so viele Daten doppelt zu speichern.

Dass parallel auch andere Verbesserungen entwickelt werden ist gut, nur irgendwie sollen die am Ende ja auch wieder zusammen komnen.

Grüße Sidey

[CaptainHook]

Moin,

Sorry mein Fehler, ich hätte die Dateien nicht einfach hier hochladen sollen.

Die Decodierung der Oregon Daten funktioniert soweit als da ich die Protokolle Empfang. Die Verarbeitung durch 41_Oregon schlägt fehl da bei meinem TN123N die Länge (bits) statt 68 nur mit 64 ankommt.
2014.08.03 14:29:08 4: OREGON: ERROR: Unknown sensor_id=ea4c bits=64 message='40EA4C109C58269094'

ggf. ist dies Fehler in der 41_Oregon.pm? Wenn ich die anpasse das sie auch mit 64Bits zufrieden ist (OREGON_type_length_key(0xea4c, 64) => ) läuft es astrein.

@Jörg: wenn du schon am Modularisieren bist hätte ich folgenden Vorschlag: Eine Datei (.cpp + .h) je Protokoll dadurch würde der Hautteil viel übersichtlicher und man könnte einfacher Teile austauschen.

Programmier-"Regeln" find ich gut. Allerdings muss ich auch lobend erwähnen, dass ich noch selten so gut lesbaren Code auf git hatte wie das FHEMduino-Projekt, Sprich sprechende Variablen, Kommentare etc.!!! 

Gruß,
Stephan

[Sidey]

Hallo captainhook,

Ich habe auch diesen Sensor, allerdings als OEM Version.
Und exakt das gleiche Ergebniss.
Hast Du  einen originalen ?

Ich habe mich mit dem Programmierer der 41_Oregon auch schon in Verbindung gesetzt, er hat mir allerdings keine Hoffnungen gemacht, dass es überhaupt funktioniert.
Eventuell wird vom rfxcom noch was zusätzlich über tragen.

Wenn sich noch weitere Personen finden die das testen, finden wir es schnell heraus.


Grüße Sidey

[CaptainHook]

Hallo Sidey,

Ich habe einen THN132N aus einem Set mit einer Wetterstation.

Gruß, 
Stephan

[Sidey]

Ich hoffe mal, dass sich noch mehr Personen finden, welche Oregon Sensoren (andere Modelle) einsetzen.

Ich denke, dann wird klarer wo der Fehler liegt.

Grüße Sidey

[Bennemannc]

Hallo,

wenn Ihr mir sagt welche Sketch ich brauche und was ich in der Config ergänzen muss, könnte ich mit meinem Raspberry testen. Habe diverse Temperatur- und Feuchtigkeitssensoren incl. Luftdruck (Version 2) und eine Wetterstation mit Wind, Temperatur, Regen (Version 3).

Gruß Christoph