New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Protokoll für 2-Kanal Funk Grillthermometer Maverick ET-733 #61
Comments
Sofern das 733 wie das 732 sendet empfängst Du das Thermometer schon. Beispielsweise: Der 1. Logeintrag würde schon mal von der Länger her passen. Wenn alles korrekt empfangen und interpretiert wurde, müsste in: Interessanter ist aber erst mal, wieso das Signal nur so selten als Manchester Signal erkannt wird und meist nur als MU erkannt wird. |
Ich habe bei fhem 5.7 ein force update durchgeführt und dann über das web interface den signalduino geflasht |
Ergänzung: Ich habe noch keine Antenne am 433Mhz Receiver (Übergangslösung, SuperHET ist unterwegs) und der Sender lag 50cm entfernt |
Bitte aktualisiere mal auf die in Entwicklung befindliche Version. update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r32/controls_signalduino.txt Danach muss der Arduino neu geflasht werden. Gerade im Bezug auf Manchester habe ich ein paar Verbesserungen einbauen können. Eventuell reicht das schon, um das Signal korrekt zu empfangen. |
erledigt, hier der neue Log, Sieht auch schon aufgeräumter aus ;-) |
Also so wie das aus schaut, sendet alle 12 Sekunden etwas ein Signal. Ganz bestimmt das Grillthermometer. Im Schnitt wird jede Minute aber eine Übertragung erkannt. Ich nehme an, das reicht aus. um Messwerte zu verwenden. Jetzt müsste man halt noch herausfinden, wie die Temperatur in Celsius umgerechnet wird. Grüße Sidey |
Vielen Dank für deine Hilfe ! Programmiert habe ich bisher hauptsächlich PHP & JS, werde mich erstmal in die Thematik einlesen. Wie startet man am besten ? Ich habe jetzt mal einen 17cm Draht an den Receiver gelötet, jetzt kommt das Signal stabiler (nur die MCs aus dem Log gefiltert):
|
Hi, vom Prinzip suchst Du dir eine der MC Nachrichten mit mindestens 11 oder 13 Byte Länge (steht in einem deiner verlinkten Seiten ). Dann identifiziert Du die Stelle an der die Temperaturwerte stehen.. Das war auch in einer der Seiten sehr gut beschrieben, was wo steht inkl. CRC Berechnung. Die Nibble in denen die Temperatur steht muss umgerechnet werden. Die Formel kenne ich nicht, wird sich aber im Code der verlinkten Projekte finden. Die Umrechnung später in ein Modul zu überführen ist "nur" noch Fleiß Arbeit. Grüße Sidey |
Leider habe ich immer unterschiedlich lange Nachrichten erhalten, auch mit dem Superhet (aber jetzt kommen die Signale wenigstens auch in 5m Abstand an) Irgendwie wird der Anfang der Nachricht nicht richtig gefunden, das Start-Pattern fehlt manchmal ganz, manchmal ist es mitten im MC String. Um Sicherzustelllen, dass das ET732 und 733 gleich sind habe ich folgendes Raspberry Pi Plug-And Play Projekt getestet und es hat auf anhieb funktioniert. Weitere Infos habe ich hier gefunden: Werde weiter experimentieren, komme aber frühestens mitte nächster Woche wieder dazu |
Hi, das was ich so gefunden habe in deinen verlinkten Posts, fällt mir nichts auf, weshalb es nicht funktioniert. Was ist deiner Meinung nach das Startpattetn? Um mehr Einblick in die Signale zu erhalten, welche empfangen werden bitte ich dich, einmal den MC Decoder zu deaktivieren (das geht über einen Set Befehl). Die Signaldaten kannst Du dann bitte hier Posten. Ein paar Minuten reichen. Vielleicht lässt sich so ja feststellen, wo es hängt. Grüße Sidey |
Implemented Module for #61 (Maverick)
Funktioniert alles? |
So, ich habe bei mir mal das Maverick mit dem sduino die Nacht durchlaufen lassen:
Ich hatte dabei nur einen Temperaturfühler fürs Fleisch angeschlossen. Die Umrechung der Temperatur scheint noch nicht zu funktionieren und die Abstände zwischen den Nachrichten kommen mir etwas lang vor, oder ist das normal? Kann ich hier sonst noch irgendwie unterstützen? |
Die Umrechnung konnte ich in den Meldungen nicht finden. Kann aber gut sein, dass es da noch Fehler gibt. Der Sendeabstand liegt so bei ca. 1 Minute. Ansonsten wären noch ein paar Infos zur verwendeten Empfänger HW und Entfernung zum Sender interessant. |
Ich habe dir mal meine Logfiles angehangen, in FHEM ist nur der SDuino mit dem Maverick definiert. Als Hardware verwende ich einen RPi 3 mit einem Arduino Nano Clone, Super-heterodyne OOK Wireless Receiver Module mit 17cm Drahtantenne. Abstand zum maverick war ca. 1m. |
Ich habe mir gestern die Sache angesehen. Die Implementierung prüft derzeit nicht wirklich, ob ein Signal vom Maverick empfangen wurde. Gegen die viele falschen Werte kann ich was machen. Das hilft aber nur bedingt, da der Sensor ja bestimmt ständig etwas übertragen hat. |
#61 added Header detection for maverick protocol
Hallo,
ich versuche gerade das Maverick ET 733 über Signalduino einzufangen. Die Mavericks sind die beliebtesten Thermometer der Grill / Smokerszene ;)
Meine Hardware: Arduino NanoV3 FTDI CLone mit Signalduino und folgendem 433Mhz Empfänger
http://www.ebay.de/itm/181862208508
Geloggt mit FHEM
Folgende Infos über das Gerät konnte ich finden:
Was ist das ET 732/733:
http://bbqpit.de/maverick-et-733-und-et-732/
Ich vermute mal dass die Protokolle vom 732 und 733 identisch sind
RFXtrx für das 732
Enable-Protocoll ist Hideki
https://www.uk-automation.co.uk/content/pdf/RFXtrx%20User%20Guide.pdf
Reverse Engineering 732
https://hackaday.io/project/4690-reverse-engineering-the-maverick-et-732
Hier wurde das Projekt mit anderer Hardware umgesetzt - inkl. Source
http://www.grillsportverein.de/forum/threads/wlan-maverick-bbq-thermometer.180407/page-18#post-1542878
Im FHEM Forum auch diskutiert
http://forum.fhem.de/index.php/topic,22977.0.html
folgende Github Projekte habe ich gefunden:
https://github.com/btodcox/BBQduino
https://github.com/wvuong/bbqsmoker
Jetzt endlich mein Log, aber keine Ahnung ob da noch was anderes mit reinfunkt.
Die beiden gemeldeten Messwerte (Temps)in den Logs müssten zwischen 21 & 25 °C liegen
Wäre es möglich das Gerät zu integrieren?
fhem-2016-01.txt
The text was updated successfully, but these errors were encountered: