FHEMduino

[amunra]

Wer hatte den Code zum PT2262 entwickelt?

http://forum.fhem.de/index.php/topic,17196.msg153856.html#msg153856 => ich und das Modul hieß mal FHEMduino_ELRO das von Marcel in PT2262 umbenannt wurde. Inhaltlich hat sich aber nichts geändert (gut vielleicht um ein paar House-Codes erweitert?). Das Thema mit den vertauschten on/off Befehlen ist bekannt, siehe Wiki Eintrag in dem verlinkten Beitrag. Ich habe es damals nicht eingebaut, da ich keine Steckdonsenschalter mit solchen Hauscode habe.

[amunra]

Das FHEM-Modul ist wohl ein FHEMduino-Clone der CUL_IT.pm. Es könnte sich ja lohnen den Sketch so anzupasse, dass die Ausgabe an die CUL_IT weitergeleitet wird und die notwendigen Änderungen dort vorgenommen werden. Damit würden wir dann ein "redundantes" FHEM-Modul einsparen.

Grüße Jörg

CUL_IT ist mir nicht bekannt, das Modul ist kein "clone" sondern eine Weiterentwicklung (um die Empfangs-Funktionalität) auf Basis des 10_IT.pm-Moduls. ;o)

[JoWiemann]

CUL_IT ist mir nicht bekannt, das Modul ist kein "clone" sondern eine Weiterentwicklung (um die Empfangs-Funktionalität) auf Basis des 10_IT.pm-Moduls. ;o)

Stimmt, hatte ich falsch im Kopf. Sorry

[Sidey]

Hi,

Wenn ich den im verlinkten Beitrag referenzierten Wiki Eintrag richtig verstehe, dann ist die Idee dass die Geräte mit dem falschen on/off code angelegt werden.
Anschließend ändert man manuell den code in der Definition.

Grundsätzlich ginge das wohl, was haltet ihr von meiner Abfrage des Hauscodes? Die ließe sich ja auch auf andere Hauscodes erweitern.

Grüße Sidey

[amunra]

Wenn ich den im verlinkten Beitrag referenzierten Wiki Eintrag dicht verstehe, dann ist die Idee dass die Geräte mit dem falschen on/off code angelegt werden.
Anschließend ändert man manuell den code in der Definition.

ja, wenn du die Definition (die vom Modul initial angelegt wird) änderst, solltes es funktionieren.

Grundsätzlich ginge das wohl, was haltet ihr von meiner Abfrage des Hauscodes? Die ließe sich ja auch auf andere Hauscodes erweitern.

Grüße Sidey

Ja, wieso nicht - ich kann leider aus Zeitgründen nicht unterstützen.  Sorry.

[amunra]

Stimmt, hatte ich falsch im Kopf. Sorry

Kein Problem.
An dieser Stelle mein Lob und Dank an alle Entwickler, die das Modul FHEMduino Projekt am Leben erhalten und bereits so viele Devices untertützt werden - weiter so.

[JoWiemann]

Grundsätzlich ginge das wohl, was haltet ihr von meiner Abfrage des Hauscodes? Die ließe sich ja auch auf andere Hauscodes erweitern.

Grüße Sidey

Hallo Sidey,

lässt sich das für alle Spielarten verallgemeinern ?!

Grüße Jörg

[Bennemannc]

Hallo Sidey,

also irgendetwas mache ich Falsch oder etwas fehlt bei meiner Installation. Ich habe den Sketch von CaptianHook genommen - da steht etwas von Version 2.2a im Quellcode. Mit dem bekomme ich nichts - bzw. wenn ich glück habe mal einen und dann nichts mehr. Wenn ich am IDE seriellem Monitor V eingebe, passiert nichts. Fehlen da noch Dateien ? Beim Compilieren wird nichts angemeckert.
Zum gegentesten nehme ich immer den angehängten Sketch - der liefert zuverlässig die Daten, leider in einem anderen Format. Das Teil stammt nicht von mir - ich habe es etwas zusammengestrichen, damit nur noch die Oregon Sachen kommen. Das lief frei nach dem Motto "try and error". Bevor ich es vergesse - bei den Sketch liegt der Eingang vom Empfänger auf D8 / PB0.

Gruß Christoph

[Sidey]

Hi Jörg,

Was meinst Du damit jetzt?

Was halt ginge ist, dass wir für invertierte Hauscodes einen Bereich festlegen in dem on/off anders belegt ist.
Bei 1-31 so wie bisher
32-63 invertiert
ab 64 vielleicht noch Eibe andere Form..


Ich habe das ja nur mal quick&dirty für einen hauscode gemacht. Wenn ich an der Fernbedienung den code ändere, dann ist das ja jedes mal ein anderer Hauscode.

Grüße Sven

[Mitch]

Tut mir leider, aber die Fotos sind sehr unscharf. Hast Du die 14_FHEMduino_Env.pm im FHEM Verzeichnis?!

Grüße Jörg

Probiere noch mal bessere Bilder.

Die 14_FHEMduino_Env.pm finde ich nicht im GIT?

[Sidey]

also irgendetwas mache ich Falsch oder etwas fehlt bei meiner Installation. Ich habe den Sketch von CaptianHook genommen -

Ja, wenn Du Oregon Scientific Support verifizieren möchtest, dann bitte den Sketch aus dem Github nehmen.
Hier der direkte Link:
https://github.com/mdorenka/fhemduino/tree/trunk/src
Und diese Module in FHEM integrieren:
https://github.com/mdorenka/fhemduino_modules/tree/trunk

Fehlen da noch Dateien ? Beim Compilieren wird nichts angemeckert.

Ich kann zum Sketch von captainhook wenig sagen, die Module und der Sketch aus dem Trunk läuft allerdings.

Zum gegentesten nehme ich immer den angehängten Sketch - der liefert zuverlässig die Daten, leider in einem anderen Format. Das Teil stammt nicht von mir - ich habe es etwas zusammengestrichen, damit nur noch die Oregon Sachen kommen. Das lief frei nach dem Motto "try and error". Bevor ich es vergesse - bei den Sketch liegt der Eingang vom Empfänger auf D8 / PB0.

Hmm, ich bin verwirrt. So wie ich dich verstehe, hast Du bisher nur Sketche aus dem Forum genommen. Die sind alle angehängte sketche. Ich habe aber schon seit Monaten keinen Sketch mehr im Forum gepostet. Also war es keiner von mir
Den Sketch im GIT, habe ich vor einigen Tagen dort eingecheckt (Samstag glaube ich). Er hat eine Version "2.1d". Dort sind einige Änderungen, welche hier im Forum diskutiert worden nicht enthalten.

Wenn es um Oregon Scientific geht, ist der im GIT meines Erachtens nach aber der, welcher zu testen ist.

Wenn Du deinen Empfänger an D8 hast, dann musst Du das im Code ändern. Der Sketch ist für Pin2 bzw. Pin3 auf einen ATMega32U ausgelegt.
#define PIN_RECEIVE 2 auf 8 ändern reicht aber nicht aus, da der Interrupt auf Pin2 festgelegt ist und über den Interrupt werden erst die decoder angeworfen.

Zusammengefasst, wenn Du weisst, wie Du die Register im AtMega ändern musst, damit der Interrupt 0 auf Pin 8 hört, kannst Du es zum laufen bringen.
Ich weiss es nicht und würde den Empfänger an Pin 2 hängen.
Ansonsten ist das rauslöschen von Code so eine Sache. Wir haben compiler Schalter eingebaut, mit denen der Compiler mitgeteilt bekommt, welchen Code er compilieren soll und welchen nicht.
Bis auf die DCF Option brauchst Du aber in der Regel nichts auskommentieren.


Grüße Sven

[Sidey]

Hi,
ich greife das noch mal auf:

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

Da ich total faul bin und sich andere Leute schon Gedanken zu derartigen Themen gemacht haben würde ich Vorschlagen wir machen es so wie hier beschrieben:

https://www.atlassian.com/de/git/workflows#!workflow-gitflow

Zusammengefasst folgende Anteile:

1. Es gibt einen Master (FHEM Module und Arduino passen zueinander, der kram läuft einfach), am besten passt das Wiki auch zu diesem Code.
- Um hier mal zu einem definierten Stand zu kommen, sollten wir schnellstens einen lauffähigen Code als Master festlegen. Alles was nicht sauber läuft lassen wir weg. Weniger Features, dafür welche die funktionieren.
2. Wir markieren den Stand im Master mit einer Versionsnummer. Meinetwegen 2.3, da es die ja bisher noch nicht gab .
3. Wir erstellen uns einen Zweig Development  (Basiert auf Master 2.3)  - jeweils für FHEMDuino und FHEMDuino_Modules
4. Für jedes Feature (PT2262 Verbesserung, Funkgong, Oregon Scientific V3, LEDs, etc.) wird ein eigener Zweig aus Development erstellt. - Den Zweig erstellen wir dort, wo er notwendig ist.
5. Ist ein Feature fertig, wird es mit den Development Zweig gemergt. 
6. Aus dem dev Zweig kann dann wieder ein Master mit neuer Version erstellt werden.   jeweils in FHEMDuino und FHEMDuino_Modules
7. Alle Probleme etc, werden auch als Issue im GIT eingetragen. Im Commit kann man sich ja darauf dann auch beziehen.
8. Wir commiten im GIT lieber öfter als zu wenig.


Den Kram mit Maintenance Releases würde ich erst mal weglassen, da es ohnehin schon etwas kompliziert ist.


Anregungen, Ideen etc. gerne willkommen.


Grüße Sven

[tomatic]

Als an der Entwicklung völlig unbeteiligter Nutzer fände ich jegliche Form der strukturierten und überschaubaren Sammlung sinnvoll. Man hat sonst schnell den Überblick verloren und muss wirklich jeden Post lesen,  um nicht Module und Sketche  zu verwenden,  die nicht zusammenpassen oder noch nicht funktionieren.  Mit o. g.  Lösung wäre klar ersichtlich,  was läuft und was eher für die Entwickler unter uns ist. So wird sich auch der FHEMduino besser verbreiten,  da auch ambitionierte Laien wie ich nicht davor zurückschrecken müssen,  so ein Projekt anzugehen.
Nur meine persönliche Meinung.
Gruß,
Thomas

Gesendet von meinem GT-N8010 mit Tapatalk

[carlos]

So finde ich es als Nutzer auch ok.
Aber warum den Master, der ja stabil ist, nicht direkt im FHEM halten.
Dann hätte man per FHEM update immer die Stabile Version.
Just my 2 cents.
Gruß
Carlos

[Bennemannc]

Hallo Sven,

das mit den Pins ist klar - stecke ich eben jedes mal um. Ist ja einfach 5ter von oben oder 5ter von unten 
Wegen dem Auskommentieren - brauch ich nicht oder sollte ich nicht, weil Teile mit genutzt werden ?
Was muss den passieren, wenn ich "V" eingebe ?

Werde weiter testen und mich melden.

Gruß Christoph