Maverick ET-733 und SIGNALduino

[rageltus]

Ok. Ich lasse es heute Abend mal eine zeit lang laufen. Wie kann ich dir die optimalen logs senden? Irgendein Filter einstellen? Wie sollte ich den verbose level einstellen?

[Sidey]

Verbose 4 auf den Signalduino.

Ein Filter ist leider in Fhem nicht möglich. Interessant sind die Zeilen die mit dem SIGNALduino Gerätenamen beginnen.

[rageltus]

Hi zusammen,

anbei das Log von eben. Kann sein, dass ich entfernt irgendwo auch eine Wetterstation reinbekomme. Gestern wurde etwas mit CUL_TX_30 und heute irgendwas mit Hideki angelegt. aber das ist nicht das maverick, da es eine temp von 3.5 und 82 luftfeuchte waren. das ist im büro definitiv zu kalt :-D

[Sidey]

Im Log kann ich sehen, dass Du das von Martinr berichtete Problem hast.

Der Taktgeber arbeitet ungenau und das Signal ist nicht mehr Manchester Konform Codiert.

[rageltus]

Hmm ok .. und nun?

[Sidey]

Ich habe leider auch keine Lösung in meiner Schatzkiste.

Eigentlich wäre das Beste, dem Sender eine gleichmäßige Taktrate zu verpassen.
Ich tippe mal mit neuen Batterien läuft der besser. Vielleicht hat der Hersteller keinen Step Up Regler verbaut.

Wenn man mit den besagten Signaldaten weiter arbeiten möchte, dann müsste man das in Fhem implementieren. Das ganze grenzt allerdings mehr an basteln.

[MartinR]

Ich tippe mal mit neuen Batterien läuft der besser. Vielleicht hat der Hersteller keinen Step Up Regler verbaut.

Hallo Sidey,

hatte ich schon probiert, keine Änderung.

Gruß Martin

[Wuehler]

Hallo,

interessieren würde ich mich dafür auch, und gerne mit testen. Im Netz habe ich noch eine weitere Quelle dazu gefunden:
https://github.com/btodcox/BBQduino
Für alle, die schon Arduino und Zubehör haben vielleicht einfach zusammenzubauen. Außerdem könnte man es evtl. so umprogrammieren, dass fhem mittels URL-Aufruf aktualisiert werden könnte.

Frohes neues Jahr und häufiges BBQ wünscht
Wühler

Edit: habe mir mal das mir fehlende Ethernet-Shield bestellt. Versand dauert aber 

[Wuehler]

Nachdem das Ethernet-Shield angekommen ist gleich mal drangesetzt und fast  zum laufen gebracht. Entweder hat das Shield einen Schaden oder ich mache etwas falsch, leider funktioniert der Zugriff über die BBQduino-Webseite noch nicht.
Im Monitor des Arduino sehe ich aber die richtigen Temperaturen. Also funktioniert die Dekodierung der Funksignale
Könnte man den Code übernehmen?
noch in Fahrenheit:

Code Auswählen Erweitern

AA 99 95 59 95 9A A9 59 A9 5A 65 95 AA
chx: 4615
Food: 81
Pit : 79
AA 99 95 59 95 9A A9 59 A9 5A 65 95 AA
chx: 4615
Food: 81
Pit : 79


[Sidey]

Hat dein Sender denn auch diese miserable Abweichungen hinsichtlich Taktrate?

[Wuehler]

Mein sduino.log sah ähnlich dem oben angehängten aus. Wie kann ich da die Taktratenabweichungen erkennen?
Mit der bbqduino-Implementierung gab es sofort die richtigen Werte. Kann es sein, dass das Protokoll nicht richtig vom Maverick implementiert wurde?

Edit: gestern abend habe ich mir den bbqduino-code zur Funkdekodierung kaum angesehen, da ich mit dem Ethernet-Shield ja nicht weiter kam. Umfangreich war der Code aber nicht. Wenn ich mich richtig erinnere war der Coding-Ansatz im aculfw ein anderer (generischerer). Daher kann man den bbqduino code vermutlich nicht übernehmen, oder?

[Sidey]

Mit einer CULfw habe ich nichts zu tun und auch dieser Thread nicht.

Es gibt verschiedene Stationen, welche in der Dekodierung durchlaufen werden.

1. Der Arduino erkennt ein valides Manchester Signal und wandelt es in die binäre Bedeutung um.

Dann wird an FHEM ein MC;... Meldung übergeben.
Mit einer von den Toleranzwerten abweichenden Taktrate passiert das nicht.
Dann wird eine MU;...Meldung übergeben.

2. Kommt eine MC Nachricht in Fhem an, dann untersucht das SIGNALDuino Modul diese Daten und Ordner es einem oder mehrerer Protokolle zu.

Wenn dies klappt, dann werden die Daten aus der MC; ... Nachricht an das Maverick Modul übergeben.

3. Das Maverick Modul versucht dann, die Meldung einem Sensor zuzuordnen und dort die Readings zu aktualisieren.


Wenn es also an Schritt #1 scheitert, dann liegt das an der fehlerhaften Taktrate.

Wenn es an Schritt #3 scheitert, dann ist es vermutlich ein Fehler in der Implementierung der Maverick Sensoren.


#1 kann man vermutlich am Sender nicht lösen. Damit wäre es notwendig, den Code aus dem bbqduino so zu adaptieren, dass die per MU;... Übergebenen Daten in ihre binäre Bedeutung umgewandelt werden.

Grüße Sidey

[Wuehler]

OK. Danke für die Erklärungen. Die drei Schritte waren mir so nicht transparent. Das hat sich auch in einem Gefühl der Verwirrung geäußert
Mit culw-Anpassung lag ich dann ja richtig und werde mal den richtigen Thread suchen.

[Sidey]

Wenn da aus CULfw Anpassungen geworden ist, kannst Du dich dann bitte noch mal melden? Ich weiss nicht, was da angepasst werden soll.

[Wuehler]

Ja klar, gerne
Ich vermute, dass im Sigduino dann gar nichts angepasst werden muss, wenn die MC-Nachrichten korrekt kommen. Allerdings vermute ich auch, dass der bbqduino-code so gar nicht zu culw passt.
Aber wenn ich den aculw-Thread richtig verstehe habe ich die aculw evtl. nur nicht richtig compilliert. Wie es richtig wäre finde ich aber auch nicht raus