FHEMduino

[Sidey]

Hallo hjgode,

also Du hast festgestellt, dass Du teilweise nur in großen Stunden Abständen etwas empfängst?

Was genau,  meinst Du mit Nachbau Empfänger? Die Typenbezeichnung des Oregon Sensors, passt irgendwie nicht so ganz zwischen Beitrag und Screenshot.

Kannst Du mal die Config der Geräte noch Posten?
Ich selbst habe auch Oregon Sensoren, die Dekodierung klappt wunderbar und Andere User haben mit dem Cresta Modul auch schon ganz gute Erfahrungen gemacht.

Wenn an den Konfigurationen alles stimmt, vielleicht kannst Du dann mal den SIGNALduino direkt mit dem OUT und GNd PIN des Sensors verbinden, das würde mich dann ja doch interessieren, weshalb es nur so sporadisch geht.

Sidey

[RappaSan]

Das ist auch genau meine Beobachtung. Bei mir treten solche Aussetzer seit ca. 2(?) Monaten auch auf - ohne die FHEM-Konfiguration verändert zu haben. Das betrifft bei mir nur den THGR228N.

[Sidey]

Hi Rappasan,

Du hast das Problem mit dem Fhemduino Stimmt?

Solche Probleme hatte ich auch mit dem Fhemduino ,  erst lief es und dann auf einmal nicht mehr. 
Mit dem Signalduino habe ich solche Probleme nicht mehr.

Sidey

[RappaSan]

Hallo Sidey,

ich beobachte Dein Signalduino-Projekt schon eine ganze Weile.
Vieleicht ist die Zeit zum Umstieg gekommen...

[hjgode]

Hallo hjgode,

also Du hast festgestellt, dass Du teilweise nur in großen Stunden Abständen etwas empfängst?

Was genau,  meinst Du mit Nachbau Empfänger? Die Typenbezeichnung des Oregon Sensors, passt irgendwie nicht so ganz zwischen Beitrag und Screenshot.

Kannst Du mal die Config der Geräte noch Posten?
Ich selbst habe auch Oregon Sensoren, die Dekodierung klappt wunderbar und Andere User haben mit dem Cresta Modul auch schon ganz gute Erfahrungen gemacht.

Wenn an den Konfigurationen alles stimmt, vielleicht kannst Du dann mal den SIGNALduino direkt mit dem OUT und GNd PIN des Sensors verbinden, das würde mich dann ja doch interessieren, weshalb es nur so sporadisch geht.

Sidey

Nachbau Empfänger (Sensor) ist ein Arudino der auf dem SensorTransmitter Sketch basiert (welcher auf dem Cresta PDF basiert). Der dazugehörende RemoteSensor Sketch verarbeitet die Daten dieses Cresta - 'Sensors' einwandfrei. Der Signalduino nur zeitweise. Zum Test habe ich den 'Sensor' noch mit Code zum Senden von Oregon THGR228N Signalen erweitert, er sendet jetzt die Temp und Feuchte Daten in beiden Formaten nacheinander (mit nem delay von 3 Sekunden). Diese Oregon-Daten werden ebenfalls nur sporadisch dekodiert.
Ist aber alles hausgemacht und ich werde wohl was eigenes stricken, da sich ja anscheinend nur der RemoteSensor und SensorTransmitter einwandfrei verstehen. Im RemoteSensor Sketch sind auch Anmerkungen zum Cresta PDF und dessen Beschreibung enthalten:
   /* I'll follow CrestaProtocol documentation here. However, I suspect it is inaccurate at some points:
   * - there is no stop-bit after every byte. Instead, there's a start-bit (0) before every byte.
   * - Conversely, there is no start-bit "1" before every byte.
   * - An up-flank is 0, down-flank is 1, at least with both my receivers.
   *
   * However, since the first start-bit 0 is hard to distinguish given the current clock-detecting
   * algorithm, I pretend there *is* a stop-bit 0 instead of start-bit. However, this means the
   * last stop-bit of a package must be ignored, as it simply isn't there.
   *
   * This manchester decoder is based on the principle that short edges indicate the current bit is the
   * same as previous bit, and that long edge indicate that the current bit is the complement of the
   * previous bit.
   */
Möglicherweise liegt es an dieser Interpretation.
Wie gesagt, nicht weiter drum kümmern. Ich mach was eigenes (wie bestehend, allerdings ohne Netzwerk).

Danke für die Hilfe

~Josef

[Sidey]

Hi Josef,

Ich habe mich schon vor einiger Zeit mit dem von dir genannten Sketch auseinander gesetzt.

Das von dir beschrieben Problem hatte ich auch bei der Sensor Transistor Lib.
Ich glaube,  die ist fehlerhaft, ich weiss nicht mehr genau was ich damals herausgefunden hatte,  aber die Präambel Synct nicht richtig.  Das die Wetterstation damit klar kommen sollen wundert mich.

Zu dem Oregon encoder kann ich dir wenig sagen.  Das habe ich nie probiert.  Ich halte mir beim Oregon Decoder an das Protokoll v 2 und das sehr genau.

Ich habe mir damals ein eigenes Protokoll ausgedacht,  welches auch im Signalduino dekoriert wird.  Hast Du daran Interesse?

Alternativ gibt es auch noch mysensor.com

Grüße Sidey

[Marc1993]

Hallo,

ich bekomme meine Elro Steckdosen nicht geschaltet. Bin vom Cubietruck auf einen kleinen Ubuntu Server umgestiegen.
Ich habe fhemduino heruntergeladen, es kompiliert ohne änderungen vorzunehmen (#define COMP_PT2262 ist ja Standartmäßig nicht ausgeklammert). Dann habe ich 00_FHEMduino.pm und 14_FHEMduino_PT2262.pm ins Verzeichnis kopiert.
FHEM erkennt meinen FHEMduino mit STATE Initialized. Soweit scheint das zu funktionieren.
An einer Teststeckdose habe ich den ElroCode 1111111110 Das entspricht ja 000000000F als IT Code. Genauer: A1.

mein define:

Code Auswählen Erweitern

define ELRO_10110_A IT 000000000F FF F0
Habe es auch mit verschiedenen odes für On/Off probiert.

Das Modul sendet (LED Leuchtet), nur was kann ich nicht sagen.

Eine ne Idee was ich falsch mache?
Gruß

[viegener]

Ich habe selbst jetzt keine ELRO-Dosen, deshalb kann ich zum Define nichts sagen, auf jeden Fall sollte sichergestellt sein, dass die HW tut..

Bist Du denn sicher, dass Dein fhemduino überhaupt senden kann? Mit anderen Worten, hast Du die Möglichkeit andere Steckdosen/Protokolle zu senden oder gar einen zweiten fhemduino haben, der als Empfänger arbeiten kann?
"LED leuchtet" ist da eher unzuverlässig 

Status initialized klingt gut, wobei zur Sicherheit auch nochmal ein Aufruf des raw-Befehls V zur Ausgabe der Version sicherstellt, dass fhem und fhemduino sich "mögen".

Gruss,
Johannes

[Marc1993]

Leider kann ich es nicht anders Prüfen als mittels LED.
Die Kommunikation zwischen FHEM und Arduino klappt da: VERSION V 2.3v FHEMduino - compiled at Oct 2 215 11:29:53

Die LED meines Senders leuchtet sowie "Daten" am Eingang anliegen. Bis jetzt hing der Sender am Cubietruck und da hats immer geklappt.

[viegener]

Bis jetzt hing der Sender am Cubietruck und da hats immer geklappt.

Nur zum Verständnis, der SENDER hing am Cubietruck oder der FHEMDUINO mit dem Sender?

Johannes

[Marc1993]

So ist meine Konstruktion. Sender am Cubietruck und FHEMDUINO am Ubuntu PC. Mittels "Magic" sind die zwei verbunden

Nein, natürlich hängt der Sender am Arduino. Wie ich schon geschrieben habe, bin ich vom Cubietruck auf einen Ubuntu-PC umgestiegen
Bis heute morgen hing er noch am Cubietruck und da ging alles.

[viegener]

Ich habe durchaus verstanden, dass Du vom cubietruck auf einen ubuntu PC umgestiegen bist. Was für mich nicht klar ist, was hat denn am cubietruck funktioniert uhnd was ist geändert worden (und warum ?)

Hattest Du bereits Elro-Steckdosen am cubietruck in Betrieb --> Wenn ja, sollten die Konfigurationen der STeckdosen weitgehend identisch sein, hier solltest Du nach Unterschieden schauen?

Hattest Du fhemduino bereits auf dem Arduino am Cubietruck? Wenn ja warum neu geflasht (war das eine zu alte Version)?

Generell es sind sehr viele Variable da: neue Plattform, neue fhemduino (-Version ?), neue Geräte?, ...
Und viele Unklarheiten: "da ging alles" würde heissen auch fhemduino und Elro ging vorher am cubietruck

[Marc1993]

Achso. Sorry.

Genau. Die Dosen waren bereits am Cubietruck in betrieb.
Das Cubieboard hat GPIO Pins. Dort habe ich direkt den Sender dran angeschlossen.
Also das FHEMDUINO habe ich heute das erste mal in Betrieb genommen.

Am Cubeitruck konnte ich direkte ELRO-Codes senden.
Mein ELRO-Code für die Teststeckdose ist 1111111110. Dann müsste mein IT-Code ja 000000000F sein. Weil aus der 1 wird eine 0 und aus der 0 ein F.
Damit geht es aber nicht.

[noice]

Schau mal ob die Verkabelung zwischen arduino und dem Sender passt. 

Gesendet von meinem Valencia2_Y100pro mit Tapatalk

[Sidey]

Schick  doch mal das ganze define und ein Foto der Steckdose.