Seltsames Verhalten eines MAX Thermostats

Begonnen von KyleK, 29 Juli 2020, 23:09:16

Vorheriges Thema - Nächstes Thema

KyleK

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?


FHEM on Raspberry Pi 3B+
CUL868
7x MAX! Thermostat, 8x MAX! Fensterkontakte
Conbee II + deConz, TradFri Lampen, Osram Smart+ Steckdosen

Wzut

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
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Hanso

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

Wzut

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)
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Hanso

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



Wzut

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.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Hanso

#6
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.

Wzut

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 :)
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

hietzi

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