Signalduino Entwicklung

[hjgode]

Moin,

Das Auswertung könntest Du so machen, dass Du dir ein dummy Signalduino definierst und die Zeilen aus dem Log via get raw zum demodulieren sendest.

Grüße Sidey

Gesendet von meinem SM-T365 mit Tapatalk

Hallo Sidey

Verstehe ich nicht 

ich kann einen zweiten FHEM verwenden, dan den ich nur den Nano mit RF_Receiver Sketch hänge, der widerum per Kabel nur mit dem PFR-130 verbunden ist. Dann setze ich global verbose 5, SIGNALduino verbose 5 und SIGNALduino DEBUG 1.
Dann kann ich noch die Zeiten und Temperatur Werte notieren und die Anzahl Reed-Relais 'Klicks'.

Würde das dan zur Analyse reichen?

Gruss

Josef

[Sidey]

Hallo Josef,

So kannst Du es auch machen.
Das debug brauchst brauchbare Du nicht, das ist nur für die demodulierung neuer Signale nützlich.
Das Signal wird ja bereits erkannt und dann zum Dekodieren an das TCM_97001 Modul übertragen.
So Wie ich die Diskussion verstanden habe, wird dort dann  ein Temp/Hum Sensor angelegt.

Dort müsste nach meinem Verständniss nun durch Björn auch die entsprechende Erweiterung erfolgen.

Aus meiner Sicht sind dazu die an das TCM_97001 Modul übergebenen Daten (diese beginnen mit s) und die dazu passenden Werte notwendig.

Grüße Sidey

Gesendet von meinem SM-T365 mit Tapatalk

[hjgode]

Hallo Sidey, Hallo Björn

ich habe das Modul 14_CUL_TCM97001.pm um die Regenwerte des Pollin PFR-130 Regenmessers erweitert:

Code Auswählen Erweitern

in sub CUL_TCM97001_Parse($$):
... 
  my $channel = undef;
  my $rainticks = undef;
  my $rainMM = undef;
...
    if (($readedModel eq "AURIOL" || $readedModel eq "Unknown")) {
...
      $temp = $temp / 10;

      # rain values Pollin PFR-130     
      $rainticks = (hex($a[2].$a[6].$a[7])) & 0x3FF; #mask n2 n6 n7 for rain ticks
      Log3 $name, 5, "CUL_TCM97001: AURIOL rainticks=$rainticks";
      $rainMM = int($rainticks / 25 + .5) * .5; # rain height in mm/qm
      Log3 $name, 5, "CUL_TCM97001: AURIOL rain mm=$rainMM";
...
    if ($hashumidity == TRUE) {
      readingsBulkUpdate($def, $msgtypeH, $valH);
    }
   
    #rain Pollin PFR-130
    if ($model eq "AURIOL") {
      readingsBulkUpdate($def, "rainticks", $rainticks);
      readingsBulkUpdate($def, "rainMM", $rainMM);
    }
...


Was meint Ihr dazu?

Wie bekomme ich das im FHEM Repository geändert, damit ich bei Updates nicht immer 'meine' Datei einspielen muss?

~Josef

[Sidey]

Hallo Josef,

Du müsstest einen Patch vorschlagen, wenn Björn den aufnimmt, dann brauchst Du es bei einem Update nicht excluden.

Allerdings glaube ich nicht, dass Björn diese Änderungen 1:1 übernehmen wird, denn soweit ich verstanden habe würde der Temp/Hum Sensor mit den Anpassungen nicht mehr funktionieren.

Es müsste noch ein Unterscheidungsmerkmal zwischen  PFR und Auriol gefunden werden.

Grüße Sidey

[pejonp]

...
ich habe das Modul 14_CUL_TCM97001.pm um die Regenwerte des Pollin PFR-130 Regenmessers erweitert:
..

Hallo Josef,

könntest du mal deine geänderte 14_CUL_TCM97001.pm anhängen. Ich würde mal testen, bin aber zu faul die Änderungen einzubauen. Danke.

Jörg.

[Hauswart]

Seit Version V 3.2.0-b10 SIGNALduino - compiled at Dec 22 2015 23:24:52 habe ich öfters das Problem, dass der State auf Opened steht anstatt Initialized... bin ich ein Einzelfall? Habe mal zur Sicherheit neu geflasht.

[Sidey]

Hallo Hauswart,

Grundsätzlich ist mir nichts bekannt, was das auslösen sollte.

Ich habe ein paar Fehler beseitigt, welche das Abstürzen eher seltener macht.
Welche Version hattest Du denn vorher und passiert es in einem gewissen Zeitraum immer wieder?

Grüße Sidey

Gesendet von meinem SM-T365 mit Tapatalk

[hjgode]

Hallo Josef,

könntest du mal deine geänderte 14_CUL_TCM97001.pm anhängen. Ich würde mal testen, bin aber zu faul die Änderungen einzubauen. Danke.

Jörg.

Hallo Jörg

ich habe die Datei noch was erweitert und ein neues Model 'PFR-130' eingeführt, dann kollidiert die Änderung nicht mit bestehenden Sensoren.

Gruss

Josef

EDIT: leider merkt sich das Teil das Model Attribute nicht und fällt immer wieder auf AURIOL zurück
EDIT2: habe den code umgestellt und jetzt merkt sich das Teil das Model. Neue 14_CUL_TCM97001.pm angehängt

[Ralf9]

Hallo Sidey,

mir ist aufgefallen, daß beim SIGNALDuino das uptime nur ca 9 Stunden (ca 32700 sek) funktioniert.
Danach kommt beim uptime als Antwort:
SIGNALduino/RAW (ReadAnswer): -32175

Hängt dies mit dem "static uint16_t times_rolled = 0" zusammen?
Mir ist nicht klar wie das mit dem "times_rolled" funktioniert.

Code Auswählen Erweitern

int getUptime()
{
unsigned long now = millis();
static uint16_t times_rolled = 0;
static unsigned long last = 0;
// If this run is less than the last the counter rolled
unsigned long seconds = now / 1000;
if (now < last) {
times_rolled++;
seconds += ((long(4294967295) / 1000 )*times_rolled);
}
last = now;
return seconds;
}

Gruß Ralf

[pejonp]

...
ich habe die Datei noch was erweitert und ein neues Model 'PFR-130' eingeführt, dann kollidiert die Änderung nicht mit bestehenden
...

Hallo Josef,

hat bei mir funktioniert.

state T: 21.5 R: 100 Rmm: 2

Die Anzeige von R: 100 was bedeutet das ? Solten da nicht vielleicht die Wippenschläge hin ? Vielleicht kannst du ja noch die die Anzeige für Total Rmm einbauen.

Ich habe ein anderes Problem, seit einiger Zeit werden die Daten von meinem Lifetec LT3594 nicht mehr richtig angezeigt. Dieser wurde sonst als ABS700 erkannt bzw. habe ich eingestellt, jetzt wechselt dieser immer wieder auf TCM97... und die Temp steht bei 32 C und bei ABS700 steht 53,8 C. Vielleicht haben andere ja ähnliche Probleme. (http://forum.fhem.de/index.php/topic,35064.msg382978.html#msg382978)

Jörg

[hjgode]

Hallo Josef,

hat bei mir funktioniert.

state T: 21.5 R: 100 Rmm: 2

Die Anzeige von R: 100 was bedeutet das ? Solten da nicht vielleicht die Wippenschläge hin ? Vielleicht kannst du ja noch die die Anzeige für Total Rmm einbauen.

Ich habe ein anderes Problem, seit einiger Zeit werden die Daten von meinem Lifetec LT3594 nicht mehr richtig angezeigt. Dieser wurde sonst als ABS700 erkannt bzw. habe ich eingestellt, jetzt wechselt dieser immer wieder auf TCM97... und die Temp steht bei 32 C und bei ABS700 steht 53,8 C. Vielleicht haben andere ja ähnliche Probleme. (http://forum.fhem.de/index.php/topic,35064.msg382978.html#msg382978)

Jörg

Hallo Jörg

bei dem Lifetec kann ich erst mal nicht direkt helfen. Irgendwie wird readedModel in den if Anweisungen 'ignoriert' und ein Sensor wechselt dann das 'Model'.

Bei mir hat das Verschieben der if(readedModel) Abfragen geholfen. Allerdings ist das eigentlich keine brauchbare Lösung. Es müssen zusätzliche verläsliche Kriterien dazukommen.

Ich habe jetzt die CRC Berechnung für den PFR-130 (heisst jetzt PFR_130 und checkCRC4) herausgefunden und eingebaut. 'R' steht proportional für die Anzahl der 'Wippenschläge', das ist der Wert der vom PFR-130 Sensor gesendet wird. Aber da wird nicht 1 für einen Wippenschlag gesendet sondern 28, 57 ... (siehe anhängendes calc).

Hast Du irgendwelche Protokoll Hinweise für den Lieftec?

Gruss und frohes Neues

~Josef

[Ralf9]

mir ist aufgefallen, daß beim SIGNALDuino das uptime nur ca 9 Stunden (ca 32700 sek) funktioniert.

Ich habe es mir nochmals genauer angeschaut, nun ist es klar warum es so nicht funktionieren kann.
Dort steht "int getUptime()" es muß aber heißen:
unsigned long getUptime()

Das mit dem times_rolled ist mir nun auch klar.

Gruß Ralf

[hjgode]

Hallo

ich habe das Modul 14_CUL_TCM97001.pm nochmals überarbeitet (wahrscheinlich nicht zum letzten Mal). Ein Regentick (Wippe schlägt um) wird mit dem Wert 25 übertragen. Eine 'Schaufel' der Wippe fasst 0,5mm Regenwasser. Die Anzahl der Ticks stimmt heute mit der Anzeige des PFR Empfängers überein: Ich habe 9 Ticks (neun Mal den Wert 25 in den Nibbles n2,n6 und n8) empfangen und die Anzeige zeigt 4,5mm.

Es wäre gut, wenn SIGNALduino die Anzahl Nibbles nicht auf 12 auffüllen würde. Dann hätte man ein zusätzliches Kriterium für den PFR-130 (Auriol).

Vielleicht kann man den PFR-130 Code in ein eigenes Modul verschieben.

Gruss

~Josef

[pejonp]

...
ich habe das Modul 14_CUL_TCM97001.pm nochmals überarbeitet (wahrscheinlich nicht zum letzten Mal). Ein Regentick (Wippe schlägt um) wird mit dem Wert 25 übertragen. Eine 'Schaufel' der Wippe fasst 0,5mm Regenwasser. Die Anzahl der Ticks stimmt heute mit der Anzeige des PFR Empfängers überein: Ich habe 9 Ticks (neun Mal den Wert 25 in den Nibbles n2,n6 und n8) empfangen und die Anzeige zeigt 4,5mm.
...

Hallo Josef,

werde heute abend einmal testen. Könntest du bitte auch ins Modul die Zeile mit der ID, Datum usw. einfügen. In etwa so:
# $Id: 14_SD_WS09.pm 1039  2016-01-01 $
Damit wir die Versionen auseinanderhalten können. Oder kann das github machen ?

Jörg

[hjgode]

Hallo Jörg

manuell Versionsnummern pflegen ist müssig und fehlerträchtig und wird gerne auch mal vergessen.

Wenn das Modul Teil von github wird, kann man jederzeit zwischen den Änderungen hin- und her wechseln.

Für die Updates innerhalb von FHEM benötigt man noch eine 'controls.txt' Datei. Diese enthält dann Anweisungen (zb UPD), den Dateinamen, Timestamp und Dateigröße für FHEM.

Als ersets müsste aber ein Name festgelegt werden, der dann wiederum in SIGNALduino benutzt werden muss, damit diese Daten nicht mehr über 14_CUL_TCM97001 laufen sondern über das neue Modul. Da Auriol und der Pollin wohl ähnlich sind, könnte man beide Sensortypen in einem Modul verarbeiten, so wie das für viele verschiedene Sensortypen derzeit im 14_CUL_TCM97001 gemacht wird.

Da sollte aber Sidey was zu sagen. Er 'macht' schließlich das SIGNALduino Modul.

~josef