Grillthermometer, z.B. Inkbird oder Maverick ??

[Invers]

Ich hänge hier mal ein Bild an.

[Prof. Dr. Peter Henning]

OK, also hier mal Input.

1. Setzen des Attributs addvaltrigger im SDuino bewirkt - gar nichts. Keine Ausgabe von extra Messages.

2. Also habe ich mal eine gepatchte Version von 1_SD_WS.pm gebaut und zusätzliche Readings mit den Status erzeugt.

- Die Status-Nibble haben den Wert 0101, wenn kein Sensor angeschlossen ist. Wird als äquivalent zu LLL = low temperature betrachtet.
- 0000 => Sensor angeschlossen und ok.

- Wenn ich jetzt am Sender die Versorgungsspannung herunterdrehe, blinkt ab etwa 2,4 V das "TX low bat"-Symbol im Empfänger. So, und jetzt kommts: Dann geht das Status-Nibble von Sensor Nr. 2 (und nur das) auf den Wert 1000 (bzw. 1101, wenn der Sensor abgezogen wird)

Unterhalb von 1,9 V piept der Empfänger, keine Funktion der Sensoren mehr. Wiederherstellung der Spannungsversorgung => Piepen hört auf.

Ich werde gleich nochmal nachlegen und den Zustand "Übertemperatur" erzeugen.

LG

pah

[elektron-bbs]

Unterhalb von 1,9 V piept der Empfänger, keine Funktion der Sensoren mehr. Wiederherstellung der Spannungsversorgung => Piepen hört auf.

Setzt da der Sensor aus, d.h. auch im FHEM kein Empfang mehr, oder wird evtl. ein anderes Bit gesetzt?

[Prof. Dr. Peter Henning]

Letzteres, Sensor setzt aus. Also nur "Battery OK", "Battery Low" oder "Tot".

Übertemperaturwarnung kommt übrigens nur im Empfänger, Sender misst brav weiter bis 120 °C, dann hab eich sicherheitshalber aufgehört.

Achja: die letzten 8 Bit wie immer wild schwankend. Irgendein CRC Code mit Message Number?

Ich habe jedenfalls im Modul jetzt ersetzt bei Protokoll 122

Code Auswählen Erweitern

# TM40, Wireless Grill-, Meat-, Roasting-Thermometer with 4 Temperature Sensors
        # -----------------------------------------------------------------------------
        # 0    4    | 8    12   | 16   20   | 24   28   | 32   36   | 40   44   | 48   52   | 56   60   | 64   68   | 72   76   | 80   84   | 88   92   | 96   100  | 104
    # 1001 0010 | 0110 0011 | 0000 0001 | 0011 0110 | 0000 0001 | 0011 0110 | 0000 0001 | 0100 0000 | 0000 0001 | 0110 1000 | 0000 0000 | 0000 0000 | 1011 1000 | 1000
        # iiii iiii | iiii iiii | 4444 4444 | 4444 4444 | 3333 3333 | 3333 3333 | 2222 2222 | 2222 2222 | tttt tttt | tttt tttt | S4 S3     | S2 S1     | CCCC CCCC | 1
        # i: 16 bit id => 9263 in example device
        # 4: 16 bit unsigned 10x temperature 4 in Celsius
        # 3: 16 bit unsigned 10x temperature 3 in Celsius
        # 2: 16 bit unsigned 10x temperature 2 in Celsius
        # t: 16 bit unsigned 10x temperature 1 in Celsius
        # s: 16 bit flags denoting sensor status S. 5 = not connected or low temp, 0 = connected
        #    if battery low, highest bit of S2 will go to one 
        # C: 8 bit check???, changes in every message.
        sensortype => 'TM40',
        model      => 'SD_WS_122_T',
        prematch   => sub { return 1; }, # no precheck known
        id         => sub { my ($rawData,undef) = @_; return substr($rawData,0,4); },
        bat        => sub {my (undef,$bitData) = @_;
                            return substr($bitData,88,1) eq "0" ? "ok" : "low";
                          },
        temp4      => sub { my (undef,$bitData) = @_;
                            return "NC" if (substr($bitData,80,4) eq '0101');
                            return SD_WS_binaryToNumber($bitData,16,31) / 10;
                          },
        temp3      => sub { my (undef,$bitData) = @_;
                            return "NC" if (substr($bitData,84,4) eq '0101');
                            return SD_WS_binaryToNumber($bitData,32,47) / 10;
                          },
        temp2      => sub { my (undef,$bitData) = @_;
                            return "NC" if (substr($bitData,89,3) eq '101');
                            return SD_WS_binaryToNumber($bitData,48,63) / 10;
                          },
        temp       => sub { my (undef,$bitData) = @_;
                            return "NC" if (substr($bitData,92,4) eq '0101');
                            return SD_WS_binaryToNumber($bitData,64,79) / 10;

Das "NC" ist eigentlich sehr hilfreich, weil es darauf hinweist, dass hier der Sensor fehlt, kollidiert aber noch mit einer Abfrage weiter unten, weil dort ein nummerischer Wert für die Temperatur angenommen wird. Vorschlag: Das so ins offizielle Modul übernehmen, und unten den Test auf nummerischen Temperaturwert irgendwie umgehen.

LG

pah

[elektron-bbs]

Achja: die letzten 8 Bit wie immer wild schwankend. Irgendein CRC Code mit Message Number?

Wahrscheinlich. Ich bin aber noch nicht dahinter gestiegen. Auffällig ist, das das niederwertigste Bit immer 0 ist. Es ändern sich immer nur max. 7 Bit.

Ich habe jedenfalls im Modul jetzt ersetzt bei Protokoll 122

Code Auswählen Erweitern


        # s: 16 bit flags denoting sensor status S. 5 = not connected or low temp, 0 = connected


Welche Messwerte liefert FHEM bei "low temp"? Negative Temperaturen zeigt das Teil ja wahrscheinlich nicht an. Welchen Messbereich erfasst das Teil eigentlich?

Das "NC" ist eigentlich sehr hilfreich, weil es darauf hinweist, dass hier der Sensor fehlt, kollidiert aber noch mit einer Abfrage weiter unten, weil dort ein nummerischer Wert für die Temperatur angenommen wird. Vorschlag: Das so ins offizielle Modul übernehmen, und unten den Test auf nummerischen Temperaturwert irgendwie umgehen.

So richtig gefällt mir das nicht. Das kollidiert im Modul nicht nur einmal und dürfte auch in anderen Auswertungen zu Konflikten führen, wenn da keine numerischen Werte erscheinen.

Wahrscheinlich habe ich noch ein weiteres Bit deuten können:

2022-08-09_18:50:15 SD_WS_122_T DMSG: W122#9267FED3FED3FED301405550BE8 - erste Nachricht
2022-08-09_19:50:08 SD_WS_122_T DMSG: W122#9267FED3FED3FED3010E5550408
2022-08-09_19:50:11 SD_WS_122_T DMSG: W122#9267FED3FED3FED3010E5550408
2022-08-09_19:50:14 SD_WS_122_T DMSG: W122#9267FED3FED3FED3010E5558208 - auto power off nach 60 min
2022-08-09_20:04:27 SD_WS_122_T DMSG: W122#9267FED3FED3FED3010E5550408 - Neustart

2022-08-12_09:21:19 SD_WS_122_T DMSG: W122#92ADFED3FED3FED3FED355D5A88 - Start mit leeren Batterien
2022-08-12_10:21:13 SD_WS_122_T DMSG: W122#92AD010E010E010E010E0080AC8
2022-08-12_10:21:16 SD_WS_122_T DMSG: W122#92AD010E010E010E010E0080AC8
2022-08-12_10:21:18 SD_WS_122_T DMSG: W122#92AD010E010E010E010E0088CC8 - auto power off nach 60 min
2022-08-12_11:07:58 SD_WS_122_T DMSG: W122#92AD010E010E010E010E0080AC8 - Neustart

2022-08-12_11:07:58 SD_WS_122_T DMSG: W122#92AD010E010E010E010E0080AC8 - erste Nachricht
2022-08-12_12:07:53 SD_WS_122_T DMSG: W122#92AD010E010E010E010E0080AC8
2022-08-12_12:07:56 SD_WS_122_T DMSG: W122#92AD010E010E010E010E0080AC8
2022-08-12_12:07:57 SD_WS_122_T DMSG: W122#92AD010E010E010E010E0088CC8 - auto power off nach 60 min
2022-08-12_13:29:38 SD_WS_122_T DMSG: W122#926DFED3FED3FED3FED355554A8 - Neustart

Es wird dann offensichtlich Bit 3 vom Status-Nibble Sensor 1 gesetzt. Die Frage wäre jetzt, ob das auch der Fall ist, wenn man den Transmitter manuell ausschaltet.

Lädst du mal bitte noch das Log vom Sensor hoch?

EDIT:
Branch wurde aktualisiert, neues Reading batteryState ok | low, transmitter on | off

Code Auswählen Erweitern

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

[Prof. Dr. Peter Henning]

dürfte auch in anderen Auswertungen zu Konflikten führen, wenn da keine numerischen Werte erscheinen

Na ja. Das muss natürlich in der "Auswertung" abgefangen werden - aber ein falscher Temperaturwert nutzt auch niemandem etwas.

Lädst du mal bitte noch das Log vom Sensor hoch?

Würd ich ja gerne. Aber wie schon geschrieben: Das Setzen von addvaltrigger hat keinerlei zusätzliche Logeinträge erzeugt.

LG

pah

[elektron-bbs]

Na ja. Das muss natürlich in der "Auswertung" abgefangen werden - aber ein falscher Temperaturwert nutzt auch niemandem etwas.

Falsche Temperaturwerte gibt es bei meiner Variante auch nicht, nur veraltete, state ist eindeutig:

Code Auswählen Erweitern


   READINGS:
     2022-08-14 13:57:50   MSGCNTLAST10MIN 0
     2022-08-14 13:57:50   batteryState    ok
     2022-08-14 13:57:50   model           SD_WS_122_T
     2022-08-14 13:57:50   state           T: 51
     2022-08-14 13:57:50   temperature     51
     2022-08-14 13:05:59   temperature2    27
     2022-08-14 13:05:59   temperature3    27
     2022-08-14 13:05:59   temperature4    27
     2022-08-14 13:07:47   transmitter     on
     2022-08-11 16:46:52   type            TM40


Würd ich ja gerne. Aber wie schon geschrieben: Das Setzen von addvaltrigger hat keinerlei zusätzliche Logeinträge erzeugt.

Mhmm, du hast keine Einträge wie RSSI, RAWMSG und DMSG in dem Log vom Sensor? Hast du irgendwelche Filter für das Filelog gesetzt?

[elektron-bbs]

Wir würden das Protokoll jetzt gerne in den Master-Branch übernehmen.
Spricht irgendetwas dagegen?

[Invers]

Hat schon jemand eine Bedienung/Auswertung für das Grillthermometer programmiert? Falls ja, wäre eine Veröffentlichung möglich? Ich hab schon versucht, aber dann vorerst aufgegeben.

[Prof. Dr. Peter Henning]

Hat schon jemand eine Bedienung/Auswertung für das Grillthermometer programmiert?

Klar.

Bedienung ist einfach: Man steckt die Thermometerspieße an der richtigen Stelle ins Fleisch. Vorsicht bei Drehspießen, hier muss man entweder alle 10 Umdrehungen die Richtung wechseln oder ein Verlängerungskabel bestellen.

Auswertung ist komplizierter: Wünsche der Gäste abfragen (z.B. "Medium"), in der Tabelle nachschlagen, welcher Kerntemperatur das entspricht. Anzeige beobachten und bei dieser Temperatur das Ding vom Grill. In FHEM: mit einem DOIF alle 60 Sekunden die gemessene Temperatur abfragen und durch ein TTS-Modul ansagen lassen. Das ermöglicht, dass man sich um die Gäste kümmert und den Grill in Ruhe lässt.

Weitere Bedienungen/Auswertungen sind m.E. vollkommen obsolet, weil man auch solche Dinge wie fehlende Sensoren oder leere Batterien spätestens bemerkt, wenn man das Ding einsetzen will.

LG

pah

[Invers]

Ja, danke.
Ich hatte schon einige Grillthermometer, daher ist mir die Bedienung geläufig.
Mir schwebte eigentlich so etwas vor, wie z.B. Auswahl der Fleischsorte und des Gargrades per Listenfeld, oder der Zieltemperatur. Für alle 4 Sensoren (bei Bedarf). Danach die Anzeige / Meldung, wenn Zieltemperatur erreicht ist, möglichst akustisch und per Push oder Mail.
Der mitgelieferte Funkempfänger wäre dann überflüssig.

[Prof. Dr. Peter Henning]

Das macht schon etwas mehr Sinn.

Allerdings würde ich das aus Gründen der Gastfreundschaft entweder per Tablet-UI oder per ChatBot realisieren.

Tablet-UI: Separate Buttons für Fleischsorte, Gewicht oder Dicke, Gargrad => heraus kommt Kerntemperatur => Button "Einstellen" => erzeugt ein "Überwachungs-DOIF"

ChatBot: Dialog, der die o.a. Parameter abfragt => Kerntemperatur wird genannt => "Soll ich das einstellen?" => Ja => erzeugt DOIF

LG

pah

[Invers]

Naja, alles schön und gut, aber das war ja nicht die Frage. Meine Frage lautete ja, ob das schon jemand programmiert hat und dieses Programm dann hier veröffentlichen würde.
Trotzdem vielen Dank.