Hallo,
beim Anschauen einiger Plots ist mir heute bei einem meiner Thermostate ein Fehlverhalten aufgefallen, dass ich mir nicht so recht erklären kann.
Im Log des Geräts tauchen um die Nachmittagszeit folgende Zeilen auf:
2020-07-29_14:00:30 MAX_Thermostat_Kinderzimmer_Greta_links RSSI: -81
2020-07-29_14:01:48 MAX_Thermostat_Kinderzimmer_Greta_links valveposition: 0
2020-07-29_14:01:48 MAX_Thermostat_Kinderzimmer_Greta_links desiredTemperature: 17.0
2020-07-29_14:01:48 MAX_Thermostat_Kinderzimmer_Greta_links RSSI: -80.5
2020-07-29_14:10:26 MAX_Thermostat_Kinderzimmer_Greta_links valveposition: 229
2020-07-29_14:10:26 MAX_Thermostat_Kinderzimmer_Greta_links 2.0°C
2020-07-29_14:10:26 MAX_Thermostat_Kinderzimmer_Greta_links desiredTemperature: 2.0
2020-07-29_14:10:26 MAX_Thermostat_Kinderzimmer_Greta_links RSSI: -41
2020-07-29_14:10:26 MAX_Thermostat_Kinderzimmer_Greta_links gateway: 0
2020-07-29_14:10:26 MAX_Thermostat_Kinderzimmer_Greta_links mode: auto
2020-07-29_14:10:26 MAX_Thermostat_Kinderzimmer_Greta_links panel: unlocked
2020-07-29_14:31:45 MAX_Thermostat_Kinderzimmer_Greta_links valveposition: 0
2020-07-29_14:31:45 MAX_Thermostat_Kinderzimmer_Greta_links 17.0°C
2020-07-29_14:31:45 MAX_Thermostat_Kinderzimmer_Greta_links desiredTemperature: 17.0
2020-07-29_14:31:45 MAX_Thermostat_Kinderzimmer_Greta_links RSSI: -81
2020-07-29_14:31:45 MAX_Thermostat_Kinderzimmer_Greta_links gateway: 1
2020-07-29_14:31:45 MAX_Thermostat_Kinderzimmer_Greta_links mode: manual
2020-07-29_14:31:45 MAX_Thermostat_Kinderzimmer_Greta_links panel: locked
Aus irgendeinem Grund wird plötzlich eine out-of-range valveposition und eine seltsame desiredTemperature gemeldet.
Das Thermostat ist aktuell eigentlich auf manuell und eco-Mode, also 17.0°C eingestellt.
Zur etwa gleichen Zeit hab ich im FHEM-Log folgende Zeilen:
2020.07.29 14:10:26 2: CM_Parse, unhandled message type B6 from MAX_750022 to MAX_f10885 - ignoring !
2020.07.29 14:13:12 2: CM_Parse, unhandled message type 06 from MAX_8a0ce6 to MAX_044207 - ignoring !
2020.07.29 14:19:04 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at /opt/fhem/FHEM/14_CUL_MAX.pm line 821.
2020.07.29 14:21:55 2: CM_Parse, unhandled message type 07 from MAX_93c194 to MAX_0a0022 - ignoring !
2020.07.29 14:24:26 2: CM_Parse, unhandled message type 0C from MAX_e90442 to MAX_WT_Greta - ignoring !
2020.07.29 14:24:42 2: CM_Parse, unhandled message type 06 from MAX_b67507 to MAX_93c100 - ignoring !
Die hier gelisteten MAX Geräte-Adressen hab ich nicht in meiner Installation.
Interessanterweise hab ich ein Gerät mit der Adresse 06b675, und im Log taucht auf b67507.
Ein wandthermostat hat die Adresse 0793c1, im Log taucht ein MAX_93c100 auf.
Zufall?
Hier noch ein List von dem Thermostat:
Internals:
CULMAX_MSGCNT 4689
CULMAX_TIME 2020-07-29 22:54:45
DEF HeatingThermostat 19940a
FUUID 5c478f23-f33f-9ecb-1221-26b2bef5fe26b2b3
IODev CULMAX
LASTInputDev CULMAX
MSGCNT 4689
NAME MAX_Thermostat_Kinderzimmer_Greta_links
NR 59
NTFY_ORDER 50-MAX_Thermostat_Kinderzimmer_Greta_links
STATE manual | 23.9°C
SVN 22368
TYPE MAX
TimeSlot 2
addr 19940a
devtype 1
type HeatingThermostat
READINGS:
2020-07-29 22:54:45 RSSI -83
2019-02-02 22:36:53 TimeInformationHour 2
2020-07-29 22:54:45 battery ok
2020-07-29 22:54:45 batteryState ok
2019-03-02 10:03:59 boostDuration 5
2019-03-02 10:03:59 boostValveposition 80
2019-10-31 11:51:36 comfortTemperature 21
2019-03-02 10:03:59 decalcification Sat 12:00
2020-07-29 22:54:45 desiredTemperature 17.0
2020-07-29 12:00:19 deviation 6.9
2019-10-31 11:51:36 ecoTemperature 17
2020-02-22 17:06:24 error invalid or missing value for READING .weekProfile
2019-03-02 19:58:40 firmware 1.0
2020-07-29 22:54:45 gateway 1
2019-09-29 19:49:05 groupid 1
2020-02-22 17:06:24 lastConfigSave ./log/MAX_Thermostat_Kinderzimmer_Greta_links.max
2020-07-29 16:31:38 lastTimeSync 2020-07-29 16:31:38
2020-06-11 19:37:02 lastcmd desiredTemperature 17.0
2019-03-02 10:03:59 maxValveSetting 100
2019-10-31 11:51:36 maximumTemperature on
2019-10-31 11:56:05 measurementOffset 0.5
2019-10-31 11:51:36 minimumTemperature off
2020-07-29 22:54:45 mode manual
2020-07-29 16:31:38 msgcnt 136
2020-07-29 22:54:45 panel locked
2020-07-29 22:54:45 peerIDs 000000,06b675,07930f,0793c1,222222
2020-07-29 22:54:45 peerList Broadcast,MAX_07930f,MAX_222222,MAX_Thermostat_Kinderzimmer_Greta_rechts,MAX_WT_Greta
2020-02-22 17:06:24 peers 0793c1
2020-07-29 22:54:45 rferror 0
2020-07-29 22:54:45 state 17.0°C
2020-07-29 12:00:19 temperature 23.9
2019-03-02 19:58:40 testresult 160
2019-03-02 10:04:00 valveOffset 20
2020-07-29 22:54:45 valveposition 0
2019-10-31 11:51:36 windowOpenDuration 15
2019-10-31 11:51:36 windowOpenTemperature 12
helper:
io:
CUL_0:
raw Z0E9C020219940A0793C10001390022
rssi -83
time 1596056085.62544
Attributes:
IODev CULMAX
alias Kinderzimmer Greta links
event-on-change-reading .*
event-on-update-reading desiredTemperature,temperature,valveposition
group Heizung
icon max_heizungsthermostat
model HeatingThermostat
room Räume->Greta,System->MAX
stateFormat mode | temperature°C
userattr Heizung Heizung_map room_map structexclude
webCmd desiredTemperature
Hat jemand ne Idee was hier passiert ist?
Zitat von: KyleK am 29 Juli 2020, 23:09:16
Hat jemand ne Idee was hier passiert ist?
Na klar ....
kurze Antwort : zerstörte Funktelegramme
lange Antwort :
Ich habe keine Ahnung wie & warum es zu verstümmelten Telegrammen kommt, entweder schickt das HT schon Mist oder ein anderes Gerät funkt dazwischen oder der CUL sieht etwas falsches. Egal, MAX! bietet nur wenig Möglichkeiten solche Telegramme zu erkennen und direkt zu verwerfen.
In 14_CUL_MAX ist eine Prüfung auf Länge drin, d.h. entspricht das Telegramm nicht den Mindestanforderungen wird es direkt verworfen und der User bekommt davon bei normalem Loglevel auch nichts mit. Leider gibt es aber auch Telegramme (wie hier schön zu sehen ist) die weiter kommen und dann bei der Auswertung Mist ergeben. Bsp : der Fehler in Bezug auf Zeile 821 in 14_CUL_MAX. Da muß ich auf jeden Fall nochmal ran.
Was mich aber echt ärgert ist das diese unsinnigen Wert es in der10_MAX bis in die Readings schaffen, ich dachte ich hätte da genug Prüfungen drin, ist aber wohl doch nicht so. :(
Fazit : mach dir jetzt keine Gedanken, behalte aber das HT mal im Auge. D.h. beschränken sich weitere Fehler nur auf dieses eine HT oder kann er auch von anderen kommen. Ich logge die bei mir ein einer extra Datei , Bsp :
2020-07-07_08:32:42 CULMAX0 unknown_message: Z1D18890CD504420E0FE4014DC8002AE85C8A0C87044201F22F01809E0029
2020-07-07_08:32:42 CULMAX0 short_message: Z02890E
2020-07-07_08:32:42 CULMAX0 short_message: Z0180
2020-07-07_08:32:42 CULMAX0 unknown_message: Z1D2F0001180D29ED860F7705030795651234560014070856F05C890F7805
2020-07-07_08:32:42 CULMAX0 short_message: Z0856FA5C890CF20442
Hallo in die Runde,
dieses Verhalten ist mir bekannt.
Wenn in der Nachbarschaft neue Max-Geräte zum Einsatz kommen
stören diese den Funkverkehr zeitweise (evtl. währen der autocreate-Phase, falls diese aktiviert sein sollte).
Ich lasse diese Geräte per autocreate erzeugen und setze anschliessend das ignore attribut auf "1".
Damit verschwinden diese 'Störungen'.
Beste Grüsse
Hans
Klar kann man machen , muß man aber nicht :)
Das IMHO doofe an der ignore Methode ist das ich ein Device im FHEM habe was ich a. nicht brauche und b. dann noch im hidden Room sein Dasein fristet.
Eleganter ist die MAX ID dieses unerwünschten Gerätes beim CUL_MAX Device auf die Blackliste zu setzen.
Bzw. noch eleganter : alle meine eigenen MAX Geräte kommen beim CUL_MAX auf die Whitelist :) dann wird alles was nicht mir ist oder in irgend einer Art und Weise verstümmelt ankommt sofort verworfen 8)
eine kleine Ergänzung - folgendes Verhalten habe ich heute festgestellt:
Trotz der MAX - ID "015348" im attribut "blacklist" wird bei aktiven autocreate ein MAX-Gerät angelegt.
siehe hier:
(in meiner Wohngegend - Innenstadtlage - ist viel los mit MAX-Geräten, wie man sehen kann.)
define cm CUL_MAX 123456
setuuid cm 5c689798-f33f-f3c5-80fc-351d7557ed209bb9
attr cm IODev CUL0
attr cm blacklist 072875 015348 020e84 020f00 0edfcd 0ee536 1008ff 0fb18b 156848 0d1fc8 15f181 0d1f32 063006 0fb2c1 0d1f39 12e340 100aff 15f187 14dff0 152848 556849 0d1f82 9008ff 15f27a 15680b 0b3406 024c0c 150e43 020b7e 0e9802 0fed71 150e7c 021b0b 150e7a 024a0e 02500e 020202 010e0c 15680e 0b3005 053006 063001 02500b 0ee502 0ece02 01880b 0b3a05 0ee102 010eb3 020e95 0e1502 010b21 063002 020cff 150e72 020e30 11758a 020e80 01880e 0b2105 053002 363039 150eba 0eb402 02130e 14a00e
attr cm fakeSCaddr 222222
attr cm fakeWTaddr 111111
attr cm myDevice yes
attr cm room 999_Sonstiges,97_USB-Devices
Lösung: Attribut ignore auf "1" gesetzt und ab mit dem Gerät in einen Dummy-Raum und in eine extra cfg-Datei die ich per include in fhem.cfg einbinde
###################################################################
## unbekannte Geräte in der Nachbarschaft #########################
include fhem_ignore_MAX.cfg
include fhem_ignore_IT.cfg
include fhem_ignore_Sonstige.cfg
include fhem_ignore_RFXtrx.cfg
include fhem_ignore_WMBUS.cfg
sorry, aber deine blacklist kann nicht greifen da die Syntax eine Komma getrennte Liste erwartet !
Und wie geschrieben, bei so einer langen Liste wirst du immer hinterher hinken. Ich würde die blacklist löschen und die Guten bei whitelist eintragen.
(natürlich auch wieder Komma getrennt)
Deine cfg includes lass ich mal aussen vor, da dies ein manuelles editieren der fhem.cfg verlangt und bei etlichen Leuten hier im Forum sofort die Schotten runterfahren und jeden weiteren Support verweigern. D.h. wenn du schon editierst dann würde ich es nicht so an die große Glocke hängen.
Hallo Wzut,
ich danke Dir.
Leider hatte ich in der Wiki keinen Hinweis auf die Syntax des "attr <device> blacklist" für CUL_MAX-Definitionen gefunden.
Und nahm an, dass wie an anderer Stelle im Wiki ein Leerzeichen als Trenner eingesetzt wird.
Merkwürdig ist dann nur, dass die in der Blacklist (mit Leerzeichen) aufgeführten MAX-Geräte nun nicht mehr
in der Geräte-Auswahl-Pull-Down-Liste des set-Kommandos der Web-Oberfläche zur Auswahl stehen, was ja richtig Sinn macht und ich u.a. beabsichtigt habe.
Z.B. "set <device> associate <Geräte-Auswahl-Pull-Down-Liste>".
Ohne blacklist-Attribut stehen dort alle Geräte auch die auf ignore gesetzen Geräte zur Auswahl.
Das war der Grund dafür, dass ich annahm, die Syntax sei ok.
Hier scheint lediglich der Perl-Code für den Aufbau der <Geräte-Auswahl-Pull-Down-Liste> auch Leerzeichen zu akzeptieren.
Wie auch immer, mit Komma als Trennzeichen läuft es jetzt bereits einige Zeit, ohne Erzeugung eines Gerätes durch das aktive autocreate.
und... danke für den Hinweis zum Thema Editieren der cfg-Dateien.
In den Konfigurationsdateien zu editieren ist eine Art 'Berufskrankheit'. Ich bin Informatiker mit über 40 Jahren Berufserfahrung
in der Software-Entwicklung.
Solche Leute können nicht anders.
Aber ich sehe es ein, dass für Puristen des fhem so etwas ein 'no-go' sein kann.
Beste Grüsse
Hans
ach ja:
Das Nutzen einer whitelist ist dann lästig, wenn Geräte ausfallen und/oder neue Geräte zum Einsatz kommen sollen.
Bisher habe ich 2 Fensterkontakte wegen Batterie-Auslauf und 2 Thermostate wegen Alterschwäche (Batterie-Fresser) austauschen müssen.
Da läuft das Anlernen und autocreate mit dem Führen einer blacklist angenehmer.
Zitat von: Hanso am 10 August 2020, 11:05:24
Leider hatte ich in der Wiki keinen Hinweis auf die Syntax des "attr <device> blacklist" für CUL_MAX-Definitionen gefunden.
---snipp-----
Ohne blacklist-Attribut stehen dort alle Geräte auch die auf ignore gesetzen Geräte zur Auswahl.
--snipp----
Da läuft das Anlernen und autocreate mit dem Führen einer blacklist angenehmer.
a. das MAX Wiki ist sehr mit Vorsicht zu geniesen, keine Ahnung wer sich darin alles verewigt hat und dann noch zum Teil mit Unwahrheiten.
Im Zweifelsfall immer an die command.ref halten ( ok da bin ich auch im Rückstand ) oder einfach hier fragen.
b. das sollte eigentlich nicht sein :( muss ich mir nochmal anschauen
c. des Menschen Wille ist sein Himmelreich :)
Ich hatte vor kurzem ein ähnliches Problem. Ein Max Thermostat war auf 17 grad manuell eingestellt. Es hat sich selbstständig auf 21 Grad manuell umgestellt.
Ich beobachte das von Zeit zu Zeit. Ist selten passiert aber manchmal
In diesem Fall war es blöd da ich dieses Thermostat als Gartensprenklersteuerung missbrauche. In der Nacht ging dann natürlich das Thermostat auf und es wurde bewässert :-)
lg
Chris