Maverick ET-733 und SIGNALduino

[Wuehler]

Hey Sidey,

dann versuche ich das mal. Ist mein erster Kontakt mit github in aktiver Entwicklerrolle 
Also bitte etwas mehr Vorsicht und auch etwas Nachsicht,
Dirk

[Papaloewe]

Hallo Dirk,

ich sehe gerade in einem anderem Thread https://forum.fhem.de/index.php/topic,77756.msg698590.html#msg698590, dass bei Einsatz mit dem RFXtrx433E die beiden Temperatur-Readings: "temp-bbq" und "temp-food" benannt sind.

Vielleicht könntest du das auch noch entsprechend anpassen? Das wäre dann "sprechender" und kompatibel zum RFXtrx.

Super Arbeit, vielen Dank.

Thomas

[Wuehler]

Hallo Thomas,

kann ich theoretisch machen, hätte dann aber Auswirkungen auf alle, die das Modul so nutzen wie es ist. Andererseits wäre es natürlich auch gut, wenn das Maverick in fhem immer dieselben Readings hat, egal ob RFXTRX oder SIGNALduino IODev sind.
Ich habe das Gefühl, dass das Maverick mit SIGNALduino bisher nicht funktioniert hat und wenn mein grep richtig funktioniert hat wird es das Modul SD_WS_Maverick auch nur in 00_SIGNALduino verwendet. Wäre also evtl. noch früh genug, es anzupassen.
@Sidey/Ralf: Was meint ihr dazu?

Grüße,
Dirk

Edit: Müsste dieser Thread nicht besser nach "Sonstige Systeme" verschoben werden, laut Maintainer.txt?

[Ralf9]

ich sehe gerade in einem anderem Thread https://forum.fhem.de/index.php/topic,77756.msg698590.html#msg698590, dass bei Einsatz mit dem RFXtrx433E die beiden Temperatur-Readings: "temp-bbq" und "temp-food" benannt sind.

Da das Maverick Modul seither sowieso nicht mit dem SIGNALduino funktioniert hat, dürfte eigenlich nichts gegen eine Anpassung sprechen.

Mir ist in dem TRX_Weather Modul aufgefallen, daß es beim ET-732 auch ein Battery Reading gibt. Herauszufinden wo die Battery Info steckt, dürfte aber sehr schwierig werden.

Ich habe auch die Info gefunden, daß der Empfänger max 300 Grad anzeigen kann, der Sensor aber max 380 Grad aushält.

Ich sehe gerade da ist auch noch das Reading "MessageType" (59)

In der Protokollbeschreibung steht

Code Auswählen Erweitern

0x6A upon startup, 0x59 otherwise

Ich habe dies testweise eingebaut, damit Ihr abschätzen könnt ob Euch diese Info was bringt.

Gruß Ralf

[Wuehler]

Sehr gut, dann im Anhang mit umbenannten Readings. Damit die alten Readings verschwinden entweder Device löschen oder folgende Befehle eingeben (ggf. SD_WS_Maverick durch deinen Devicename ersetzen):

Code Auswählen Erweitern

deletereading SD_WS_Maverick temp1
deletereading SD_WS_Maverick temp2


Mit dem Reading MessagType kann man erkennen, ob das Maverick gerade eingeschaltet wird (oder rsync gedrückt wurde). Habe das aber aus dem state (S:) entfernt.
Damit könnte man evtl. mal einen Mechanismus implementieren, der zum Start den eindeutigen Code ermittelt und diesen dann als ID verwenden um mehr als ein Maverick-Device nutzen zu können. Aber da soll erstmal jemand kommen, der zwei Grillthermometer zu Hause hat 

[Wuehler]

Hi Thomas,
In der Version oben habe ich leider Fühler 2 als temp-food und Fühler 1 als temp-bbq genommen. Bei meinem Maverick-Empfänger ist es andersrum. Habe das geändert und bei Sidey im PullRequest auf github. Wenn er den annimmt müsste das Modul über das normale Update kommen. Für dich sollte sich nichts in fhem ändern. Musst nur beim grillen die Fühler wieder normal stecken.

Gruß,
Dirk

[Wuehler]

Hallo,

ich habe das Modul ein wenig umfangreicher gemacht. Ist gerade im Review bei Sidey (Danke dafür) und kommt dann hoffentlich bald ins normale Update.. Da ich die nächste Woche unterwegs bin hier ein paar Infos zum Update:

• neue Readings für die Sensoren mit den Werten connected, disconnected oder inactiv
• neues Attribut inaktivityInterval: Setzt die Sensoren-Readings nach definierter Anzahl Sekunden auf inactiv (default 360 Selunden, etwas länger als das default von event-on-change-reading=300)
• die Temperatur-Readings umbenannt in temp-food und temp-bbq
• Reading state: Startup entfernt, da nicht wirklich relevant und nur per stateFormat gesetzt, also individuell änderbar
• reading messageType hat die Werte sync oder normal
• neues Reading checksum, ist noch experimentell. Mache damit eine Messreihe um herauszubekommen ob da noch irgendwo Infos zum Batteriezustand enthalten sind
  commandref angepasst (schien eine Kopie von SD_WS07 gewesen zu sein)
  --> offen dort: Wird das Protokoll 47 auch von CUL und CUN erkannt? Habe in CUL.pm nichts gefunden, die Doku aber erstmal nicht angepasst.

@Thomas: Am besten löscht du dein bestehendes Device nach dem Update. Ausserdem musst du notifies usw. anpassen. Die Temperatur wird nicht mehr auf -1 gesetzt, muss man über den state oder Sensor-state mitbekommen wenn etwas ganz aus dem Ruder läuft. Das macht plots aber schöner, falls man ab und zu doch mal Empfangsprobleme hat, da wird die Plateauphase nicht versaut

VG,
Dirk

[Wuehler]

ausserdem gibt es ein (noch) experimentelles Reading für die checksumme. Da brauche ich ein wenig Hilfe, wie man folgenden c-code in perl übersetzt. Kann das jemand übernehmen?

Code Auswählen Erweitern

uint16_t shiftreg(uint16_t currentValue) {
    uint8_t msb = (currentValue >> 15) & 1;
    currentValue <<= 1;
    if (msb == 1) {
        // Toggle pattern for feedback bits
        // Toggle, if MSB is 1
        currentValue ^= 0x1021;
    }
    return currentValue;
}

//data = binary representation of nibbles 6 - 17
//e.g. xxxx:xxxx:xxxx:0010:1000:1010:0110:0101:0101:xxxx:xxxx:xxxx:xxxx
//  -> uint32_t data = 0x28a655
uint16_t calculate_checksum(uint32_t data) {
    uint16_t mask = 0x3331; //initial value of linear feedback shift register
    uint16_t csum = 0x0;
    int i = 0;
    for(i = 0; i < 24; ++i) {
        if((data >> i) & 0x01) {
           //data bit at current position is "1"
           //do XOR with mask
          csum ^= mask;
        }
        mask = shiftreg(mask);
    }
    return csum;
}

Anschließend kann man das Modul erweitern, so dass man mehrere Mavericks gleichzeitig nutzen kann bzw.  durch das Maverick des Nachbarn keine Störsignal bekommt.

Folgende Beispieldaten helfen vielleicht:

Code Auswählen Erweitern

2018.03.15 19:05:23 4: SD_WS_Maverick: SD_WS_Maverick (599599A9599A6996A66A)
2018.03.15 19:05:23 4: SD_WS_Maverick statistic: checksum=12213113, t1=20223, temp-food=23, t2_20223, temp-bbq=23;
2018.03.15 19:05:35 4: SD_WS_Maverick: SD_WS_Maverick (599599A95A56956669AA)
2018.03.15 19:05:35 4: SD_WS_Maverick statistic: checksum=20111233, t1=20223, temp-food=23, t2_20301, temp-bbq=29;
2018.03.15 19:05:47 4: SD_WS_Maverick: SD_WS_Maverick (599599A95A666596999A)
2018.03.15 19:05:47 4: SD_WS_Maverick statistic: checksum=10212223, t1=20223, temp-food=23, t2_20311, temp-bbq=33;
2018.03.15 19:05:59 4: SD_WS_Maverick: SD_WS_Maverick (599599A95A6956A5AA95)
2018.03.15 19:05:59 4: SD_WS_Maverick statistic: checksum=01303320, t1=20223, temp-food=23, t2_20312, temp-bbq=34;
2018.03.15 19:06:23 4: SD_WS_Maverick: SD_WS_Maverick (599599A95A666596999A)
2018.03.15 19:06:23 4: SD_WS_Maverick statistic: checksum=10212223, t1=20223, temp-food=23, t2_20311, temp-bbq=33;
2018.03.15 19:06:35 4: SD_WS_Maverick: SD_WS_Maverick (599599A95A5AA95A55A6)
2018.03.15 19:06:35 4: SD_WS_Maverick statistic: checksum=32030031, t1=20223, temp-food=23, t2_20303, temp-bbq=31;
2018.03.15 19:06:59 4: SD_WS_Maverick: SD_WS_Maverick (599599A95A56956669AA)
2018.03.15 19:06:59 4: SD_WS_Maverick statistic: checksum=20111233, t1=20223, temp-food=23, t2_20301, temp-bbq=29;
2018.03.15 19:07:11 4: SD_WS_Maverick: SD_WS_Maverick (599599A95A559A6966A9)
2018.03.15 19:07:11 4: SD_WS_Maverick statistic: checksum=23121132, t1=20223, temp-food=23, t2_20300, temp-bbq=28;

Ausserdem folgende Code aus dem Maverickmodul:

Code Auswählen Erweitern

my $messageType = substr($rawData,0,2);   # 0x6A upon startup, 0x59 otherwise
my $temp_str1 = substr($rawData,2,5);
my $temp_str2 = substr($rawData,7,5);
my $checksum_str = substr($rawData,12);
...

    $temp_str1 =~ tr/569A/0123/; # Ersetzen in besser lesbaren quartären code:


Weitere Infos unter:
https://forums.adafruit.com/viewtopic.php?f=8&t=25414&sid=e1775df908194d56692c6ad9650fdfb2&start=15#p321384

[Papaloewe]

Wenn Du in der Protokolldefinition 47 die Zeile 1018 löscht, müsste es funktionieren. 

Code Auswählen Erweitern

Zeile 1018   polarity => 'invert'

Gruß Ralf

Hallo Ralf,

habe heute das fhem-update gemacht und die 00_SIGNALDUINO.pm wurde wieder überschrieben.
Darin habe ich die Stelle gefunden, aber die Stelle scheint schon auskommentiert zu sein:

Code Auswählen Erweitern

  "47"    => ## maverick
{
            name => 'Maverick protocol',
id          => '47',
clockrange      => [180,260],                   
format => 'manchester',
preamble => 'P47#', # prepend to converted message
clientmodule    => 'SD_WS_Maverick',   
modulematch     => '^P47#[569A]{12}.*', 
length_min      => '100',
length_max      => '108',
method          => \&SIGNALduino_Maverick, # Call to process this message
#polarity => 'invert'
},


Sorry, aber wie schon erwähnt: Ich zähle mich nicht zu den Programmierern.

Gleiches Ergebnis: Maverick empfängt keine Daten und es wird nur "defined" angezeigt.
Nach Austausch gegen deine letzte Version hier aus dem THread und einem relaod ist alles wieder gut.

Wäre schön, wenn du das vielleicht mit Sidey, oder wem auch immer abstimmen könntest.

Lieben Dank.
Thomas

[Sidey]

Wäre schön, wenn du das vielleicht mit Sidey, oder wem auch immer abstimmen könntest.

Kannst Du mal die Module aus diesem Branch verifizieren?

https://github.com/RFD-FHEM/RFFHEM/tree/dev-r33

Grüße Sidey

[Ralf9]

Ich habe was in der 00_Signalduino gefunden, bitte nochmals testen

Gruß Ralf

[Papaloewe]

Hallo Ralf,

mach ich gerne, aber wo finde ich die Version, die ich testen soll?

LG
Thomas

[Ralf9]

Die 00_Signalduino findest Du hier:
https://github.com/RFD-FHEM/RFFHEM/tree/dev-r33

Code Auswählen Erweitern

update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt

Gruß Ralf

[Papaloewe]

Ja, perfekt. Jetzt funktioniert es wie es soll.

Danke Ralf

[Sidey]

Das bedeutet, ich kann die Änderungen in das normale FHEM Update bringen.

Danke für die Rückmeldung.

Gruß Sidey