Empfang BBQ-Thermometer Maverick ET 732

Begonnen von unimatrix, 27 April 2014, 19:43:25

Vorheriges Thema - Nächstes Thema

knochenmuehle

Ja, am Anfang klappt das ja auch noch, aber später landet es in trx else.

Andreas


Willi

Ok. Habe jetzt verstanden.

Eigentlich sollte es gemäß regex nicht in TRX_ELSE landen.
Wichtig ist, dass Du auch 46_TRX_ELSE.pm ausgetauscht hast. Darin muss jetzt in Zeile 44 stehen:
Zitat$hash->{Match}     = "^..(0[0-f]|1[a-f]|2[1-f]|3[0-f]|4[0-d]|4f|53|59|5e|5f|[6-f][0-f]).*";
Und in 45_TRX.pm muss ab Zeile 60 folgendes stehen:
Zitatmy %mc = (
    "1:TRX_WEATHER"      => "^..(4e|50|51|52|54|55|56|57|58|5a|5b|5c|5d).*",
    "2:TRX_SECURITY"    => "^..(20).*",
    "3:TRX_LIGHT"   => "^..(10|11|12|13|14|15|16|17|18|19).*",
    "4:TRX_ELSE"      => "^..(0[0-f]|1[a-f]|2[1-f]|3[0-f]|4[0-d]|4f|53|59|5e|5f|[6-f][0-f]).*",
  );

Oder hast Du schon ein update gemacht? Ich habe gerade gesehen, dass meine Änderungen leider noch nicht im update drin sind. War wohl nur etwas zu spät. Da müssen wir auf morgen warten.
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

knochenmuehle

hatte schon ein Update gemacht und es passt alles, die Änderungen sind da ...

ohne longids klapps jetzt auch ... werde jetzt noch weiter testen und ein paar Mal ein-und ausschalten.

Gruß Andreas

knochenmuehle

mehrfach ein-und ausgeschaltet, es funktioniert alles.
Daten kommen alle 12 sek. durch 2 Wände, ca. 5m Entfernung.

Gute Arbeit ... jetzt noch das BBQ MOdul ;)

Gruß Andreas

Willi

Ok. Danke für die Info. dann lag es evtl. an dem update, sofern Du kein "shutdown restart" gemacht hast.

Ansonsten in log/fhem-2016-02.log, ob dort Fehlermeldungen zu der Zeit sind, als es ins TRX_ELSE ging.
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

igami

Ich muss aber auf jeden Fall noch ein Update der Firmware machen, oder?
Habe ein Maverick 732
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

Willi

Zitat von: igami am 08 Februar 2016, 16:29:32
Ich muss aber auf jeden Fall noch ein Update der Firmware machen, oder?
Habe ein Maverick 732
Firmware-Update nur, wenn die Firmware das Maverick 732 noch nicht unterstützt.
Ich habe gerade mal bei RFXCOM nachgesehen. Der RFXtrx433 unterstützt Maverick 732 bereits seit der FW release 433_70    11-11-2013, also schon sehr lange. Daher ist bei Dir vermutlich kein Firmware-Update notwendig.

Schau Dir mal die fhem-2016-02.log an, was als Firmware angezeigt wird.

Bei mir steht da
Zitat2016.02.08 16:53:15 1: TRX: Init status: '433.92MHz transceiver, firmware=174, protocols enabled: RSL LaCrosse Hideki OREGON ARC X10 '
Also selbst bei mir würde das Maverick erkannt werden.

Willst Du allerdings die ID, musst Du auf die neue Firmware updaten:
ZitatFW release 433_95/195/251 06-02-2016
    OWL CM180 ID improved
    Maverick ET-733 added
    Maverick ET-732 ID added (Type2 & Ext only)
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

igami

#172

2016.02.02 21:07:11 1: TRX: Init status: '433.92MHz transceiver, firmware=248, protocols enabled: OREGON AC ARC X10 '

Habe aber eben auch ein update der Firmware gemacht

2016.02.08 17:07:37 1: TRX: Init status: '433.92MHz transceiver, firmware=251, protocols enabled: OREGON AC ARC X10 '


Aber mein Maverick wird nicht per autocreate angelegt, habe die Module welche mittels update ausgeliefert werden.

Edit: Habe erst jetzt gelesen, dass die Dateien erst morgen kommen :D
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

knochenmuehle

Zitat von: igami am 08 Februar 2016, 17:11:43
Aber mein Maverick wird nicht per autocreate angelegt, habe die Module welche mittels update ausgeliefert werden.

Du brauchst als Protokoll auch noch Hideki.

Andreas

igami

Zitat von: knochenmuehle am 08 Februar 2016, 17:20:54
Du brauchst als Protokoll auch noch Hideki.

Und was muss ich dafür machen?  ???
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

knochenmuehle

Zitat von: igami am 08 Februar 2016, 17:25:42
Und was muss ich dafür machen?  ???

mit dem RFXmngr aktivieren z.B. an der Windows Maschine...

Andreas

igami

Zitat von: knochenmuehle am 08 Februar 2016, 17:28:40
mit dem RFXmngr aktivieren z.B. an der Windows Maschine...

Vielen Dank, läuft alles :)
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

knochenmuehle


2016-02-10_14:42:33 ET732 temp-food: 65004
2016-02-10_14:42:33 ET732 temp-bbq: 22
2016-02-10_14:42:33 ET732 battery: ok
2016-02-10_14:42:33 ET732 TF: 65004 TB: 22 BAT: ok


das passiert beim 733er, wenn nur ein Temperaturfühler angeschlossen ist. Sieht im Plot Scheiße aus ...
Wie kann ich den 65004 Wert auf 0 oder -- setzen ?

Andreas

Willi

#178
Wenn ich das richtig sehe, kann Maverick 733 nur bis maximal 380 Grad.

Es macht m.E. Sinn, das entsprechende Readings überhaupt nicht zu generieren, wenn die Temperatur zu hoch ist. Vorschlag wäre den Code in 46_TRX_WEATHER.pm entsprechend abzuändern, dass bei Überschreitung von beispielsweise 1000 (1000 Grad) das Reading überhaupt nicht generiert wird. Das Setzen auf 0 wäre dann ja auch falsch.

Oder gibt es einen anderen Vorschlag?
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

knochenmuehle

Zitat von: Willi am 10 Februar 2016, 16:02:31


Es macht m.E. Sinn, das entsprechende Readings überhaupt nicht zu generieren, wenn die Temperatur zu hoch ist. Vorschlag wäre den Code in 46_TRX_WEATHER.pm entsprechend abzuändern, dass bei Überschreitung von beispielsweise 1000 (1000 Grad) das Reading überhaupt nicht generiert wird. Das Setzen auf 0 wäre dann ja auch falsch.

von hier: Zustimmung zu deinem Vorschlag

Andreas