Temperatursender von Wetterstation in CUL

[Ralf9]

Dann sag mir doch mal bitte welche Zeiten so ein lander Impuls 12/16 - 16/124 hat, wie sind die Werte zu interpretieren?
Bzw. was ist eine Einheit.

In der culfw commandref steht folgendes (Bit 4):

Code Auswählen Erweitern

X<RR>
    Enable data reporting for SlowRF (i.e. 1kHz data rate)
    <RR> is a one-byte hex value, with following bits (bit 0 is the LSB bit):
        Bit 0: Report known messages (parity & checksum ok), with type prefix.
        Bit 1: Report each of the (repeated) packets of a message
        Bit 2: Report detailed data, even with wrong parity / checksum.
        Bit 3: Monitor mode: output an r on a risings edge and 'f' on a falling edge. Output a '.' at the end of the message (no signal for 4msec).
        Bit 4: Timing: in monitor mode output one additional byte of the internal microsecond timer, divided by 16. This is binary!
        Bit 5: RSSI: report RSSI value as an additional HEX byte after digested data or as a separate byte if Bit 3 is set too.
        Bit 6: Report FHT protocol messages (ack, etc)
        Bit 7: CUL/CUN: Report raw RSSI data (a==weak ... p==strong signal) CUR: Grafic representation: dark==weak ... light == stong signal


[Sidey]

Also ich kann die Daten leider nicht interpretieren, habe auch keinen cul.

Ich bräuchte so was, wie man es aus einem Oszi ablesen könnte.
Wie lang ist der 1. Puls, wie lang der 2. usw und dazu dann noch die Pegelstände high oder low.

Grüße Sidey

[bjoernh]

Also ich kann die Daten leider nicht interpretieren, habe auch keinen cul.

Ich bräuchte so was, wie man es aus einem Oszi ablesen könnte.
Wie lang ist der 1. Puls, wie lang der 2. usw und dazu dann noch die Pegelstände high oder low.

Grüße Sidey

Dito...
ich blicks auch auf die Schnelle auch nicht.
@Rudi: Kannst Du uns bitte mal auf die Sprünge helfen?

Gruß
Björn

[rudolfkoenig]

Ich habe X18 mit culfw/tools/timer.c interpretiert (wenn ich mich recht erinnere, immerhin ist es 6 Jahre her).
Danach ist

Code Auswählen Erweitern

72 0f 66 02 72 2a 66 de
als r:240ms f:32ms r:672ms f:3552ms zu lesen.

[bjoernh]

Ich habe X18 mit culfw/tools/timer.c interpretiert (wenn ich mich recht erinnere, immerhin ist es 6 Jahre her).
Danach ist

Code Auswählen Erweitern

72 0f 66 02 72 2a 66 de
als r:240ms f:32ms r:672ms f:3552ms zu lesen.

Danke, dann sieht es ja so aus, als ob es ganz anders Aufgebaut ist als die TCMs.

[Sidey]

Das ist es definitiv. Es verwendet eine andere Signal Codierung

[Ralf9]

Ich glaube es macht mit dem CUL keinen Sinn, die Codierung herauszufinden.

Ich werde mir einen SIGNALDuino zusammenbauen und dann damit testen.

Gruß Ralf

[Sidey]

Jo, denke daran, dass Du ein 868 MHz Modul benötigst.

[Ralf9]

Jo, denke daran, dass Du ein 868 MHz Modul benötigst.

Auf dem EAS 800 z steht 433 MHz. Ist dann nicht ein 433 MHz Modul besser geeignet?

Gruß Ralf

[Sidey]

Hi Ralf,

dann natürlich 433 MHz.
Irgendwas muss ich verwechselt haben.

Grüße Sidey

[Ralf9]

Der Eurochron EAS 800 Z funktioniert inzwischen auf dem SIGNALduino wie gewünscht.
Beim EAS 800 Z ist mir folgendes aufgefallen. Er ist nur bedingt außentauglich, da die Batterieabdeckung keine Gummilippe hat und nur gesteckt ist.
Ich mußte im Modul einige Plausibilitäts- und Werteüberprüfungen einbauen, da das Protokoll keine Prüfsumme hat.

Das dafür erforderliche neue Modul ist so gut wie fertig. Danke an Sidey für die Hilfe.
Da ich von dem EAS 800 Z nicht vorhabe mehr als drei zu kaufen, enthält der devicecode des EAS 800 Z per default nur den Kanal.
Damit bleibt beim Batterewechsel der devicecode gleich.

Damit auch mehr als 3 Sensoren benutzt werden können, habe ich im Hauptmodul 00_SIGNALduino.pm das "attr devicecodeWithId" hinzugefügt.
Damit kann man bei Bedarf festlegen, daß der devicecode zusätzlich zum Channel auch die ID enthält. Z.B. EAS800z_4E2 bei ID=4E und Channel 2.

Es wäre schön, wenn man beim attr "devicecodeWithId" die Module einzeln festlegen könnte wie beim room attr,
dazu reichen meine Kenntnisse aber nicht aus.
Ist so ein Auswahlfenster, bei dem mehrere optionen ausgewählt werden können,  wie beim "attr room" aufwendig und komplizert zu programmieren? Gibt es dafür Beispiele?

Gruß Ralf

[Sidey]

Hi Ralf,

ich habe mir gerade aus einem anderen Grund das  46_TRX_Weather Modul angesehen.
Dort hat jemand das Problem, zumindest verstehe ich den Code so, schon mal gelöst.

Er hat es auch über eine Variable im IO Device realisiert.
Genannt hat er es longids genannt.

Code Auswählen Erweitern


  if (defined($attr{$iohash->{NAME}}{longids})) {
  $longids = $attr{$iohash->{NAME}}{longids};


Vielleicht sollten wir das exakt genau so machen, anstatt einen neuen Syntax zu erzeugen, das würde dann auch zum 41_OREGON Modul passen, welches der Signalduino ja auch nutzt.
Dort hat man ja quasi das gleiche Thema wie mit dem EAS800z. Dann wäre es einheitlicher.

Grüße Sidey

[Ralf9]

ich habe mir gerade aus einem anderen Grund das  46_TRX_Weather Modul angesehen.
Dort hat jemand das Problem, zumindest verstehe ich den Code so, schon mal gelöst.

Er hat es auch über eine Variable im IO Device realisiert.
Genannt hat er es longids genannt.

Ja, da spricht eigentlich nichts dagegen.
Ob das attr devicecodeWithId oder longids heißt, spielt keine Rolle.

Kannst Du das mit dem longids mal in die 00_SIGNALduino.pm einbauen?

Gruß Ralf

[Sidey]

jo, ich bau das ein, bzw. übernehme es von den TRX Modulen

[Sidey]

Gut, der  Status ist jetzt wie folgt:

Wird ein SIGNALduino verwendet, dann wird longid, sofern gesetzt, abgefragt.

Wird ein anderes IO Device genutzt, dann läuft das ganze ohne longid.

Es gibt noch andere Sensoren, welche den gleichen Encoder verwenden. Wie man die Modellseitig auseinander halten kann, weiss ich aktuell noch nicht.

Das Modul legt jetzt zumindest auch ein Device an, wenn ein reiner Temp Sensor empfangen wird.

Da so keine gescheitert Erkennung der Modelle möglich ist sollten wir vielleicht einfach die Modelle temp und temphum erzeugen und das nicht an der Modellbezeichnung der vorliegenden Sensoren fest machen.

Dann wäre halt noch zu Überlegen, ob wir das Modul nicht in etwas generisches umbenennen, da es ja vom Prinzip auch von anderen IO Device genutzt werden könnte.

Grüße Sidey