Fehler im Weekprofile

Begonnen von John, 07 Dezember 2013, 12:09:27

Vorheriges Thema - Nächstes Thema

John

Hallo Matthias,
möglicherweise gibt es ein Problem beim Anlegen der Wochenprofile.

Es ist doch richtig, dass ein
set HT.HW desiredTemperature auto
den AUTO Mode aktiviert und daraufhin das Thermostat den Sollwert aus dem Wochenprofil verwendet.

Der nachfolgend beschriebene Fehler ist gut reproduzierbar.

-------------------------------------------------------
Wir setzen das Wochenprofil so, dass wir uns im 2. Bereich von 3 Bereichen befinden. (jetzt=Samstag 11:40)

set HT.HW weekProfile Sat 16,06:00,16,11:50,16

EventMonitor:
Zitat
2013-12-07 11:42:35 MAX HT.HW weekProfile Sat 16,06:00,16,11:50,16
2013-12-07 11:42:36 MAX HT.HW mode: auto
2013-12-07 11:42:36 MAX HT.HW battery: ok
2013-12-07 11:42:36 MAX HT.HW desiredTemperature: 17.0
2013-12-07 11:42:36 MAX HT.HW valveposition: 15
2013-12-07 11:42:36 MAX HT.HW 17.0 °C
2013-12-07 11:42:37 MAX HT.HW weekprofile-0-Sat-time: 00:00-06:00 / 06:00-11:50 / 11:50-00:00
2013-12-07 11:42:37 MAX HT.HW weekprofile-0-Sat-temp: 16.0 °C / 16.0 °C / 16.0 °C
2013-12-07 11:42:37 MAX HT.HW weekprofile-1-Sun-time: 00:00-06:00 / 06:00-12:00 / 12:00-00:00
2013-12-07 11:42:37 MAX HT.HW weekprofile-1-Sun-temp: 16.0 °C / 16.0 °C / 16.0 °C
2013-12-07 11:42:37 MAX HT.HW weekprofile-2-Mon-time: 00:00-06:00 / 06:00-12:00 / 12:00-00:00
2013-12-07 11:42:37 MAX HT.HW weekprofile-2-Mon-temp: 16.0 °C / 16.0 °C / 16.0 °C
2013-12-07 11:42:37 MAX HT.HW weekprofile-3-Tue-time: 00:00-06:00 / 06:00-12:00 / 12:00-00:00
2013-12-07 11:42:37 MAX HT.HW weekprofile-3-Tue-temp: 16.0 °C / 16.0 °C / 16.0 °C
2013-12-07 11:42:37 MAX HT.HW weekprofile-4-Wed-time: 00:00-06:00 / 06:00-12:00 / 12:00-00:00
2013-12-07 11:42:37 MAX HT.HW weekprofile-4-Wed-temp: 16.0 °C / 16.0 °C / 16.0 °C
2013-12-07 11:42:37 MAX HT.HW weekprofile-5-Thu-time: 00:00-06:00 / 06:00-12:00 / 12:00-00:00
2013-12-07 11:42:37 MAX HT.HW weekprofile-5-Thu-temp: 16.0 °C / 16.0 °C / 16.0 °C
2013-12-07 11:42:37 MAX HT.HW weekprofile-6-Fri-time: 00:00-06:00 / 06:00-12:00 / 12:00-00:00
2013-12-07 11:42:37 MAX HT.HW weekprofile-6-Fri-temp: 16.0 °C / 16.0 °C / 16.0 °C
[/font]

Ein
set HT.HW desiredTemperature auto
liefert nun im EventMonitor

Zitat
2013-12-07 11:43:42 MAX HT.HW desiredTemperature auto
2013-12-07 11:43:43 MAX HT.HW mode: auto
2013-12-07 11:43:43 MAX HT.HW battery: ok
2013-12-07 11:43:43 MAX HT.HW desiredTemperature: 16.0
2013-12-07 11:43:43 MAX HT.HW valveposition: 15
2013-12-07 11:43:43 MAX HT.HW 16.0 °C
[/font]

Dies ist korrekt
-------------------------------------------------------
Wir warten bis wir in den 3. Bereich gelangen und setzten den Befehl erneut ab. (nach 11:50 Uhr)

set HT.HW desiredTemperature auto

EventMonitor
Zitat
2013-12-07 11:53:28 MAX HT.HW desiredTemperature auto
2013-12-07 11:53:29 MAX HT.HW mode: auto
2013-12-07 11:53:29 MAX HT.HW battery: ok
2013-12-07 11:53:29 MAX HT.HW desiredTemperature: 17.0
2013-12-07 11:53:29 MAX HT.HW valveposition: 0
2013-12-07 11:53:29 MAX HT.HW 17.0 °C
[/font]

Hier wäre doch nun eigentlich wie zuvor 16 zu erwarten, aber es wird 17 gesetzt.

John

Nachtrag:
Bereich 1 und 2 funktionieren, Fehler tritt nur bei Bereich 3 auf.
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

Harald

#1
Hallo zusammen,

ich habe das gerade bei mir getestet. Auch mit Cube gibt es die gleiche Erscheinung. In der originalen MAX!-Software steht das Tagesprogramm durchgehend auf 16°C, aber nach dem programmierten Schaltpunkt steht auf der Übersichtsseite 17°C. Das Tagesprogramm bleibt bei 16°C.

Auch ein nochmaliges set desiredTemperature auto ändert nichts, es bleibt bei 17°C. Mir ist aufgefallen, dass nach dem aktivieren des normalen Tagesprogramms in den Internals STATE auf 17°C stand, obwohl desiredTemperature schon auf 20°C war. Vielleicht kommt die "falsche" Temperatur von dort?

Viele Grüße

Harald
Router:AVM7590 1&1 FW:FRITZ!OS 07.56 Anbindung:1&1 50/10 Mb/s, WLAN-Repeater 300E
ELV MAX!Cube, 7xThermostat, ECO, RasPi 4B mit bullseye auf Festplatte,
CUL V 1.67, JeeLink v3_10.1c, nanoCUL, 1xS300TH, 4xHMS100T, 4xELRO, 1xTFA, 2xMAX_FK
ELV MAX!1.4.5, FHEM 5.7 auf RasPi, Kostal PIKO plus

John

Folgenden Workaround habe ich gefunden:

Man muss dafür sorgen, dass der letzte Bereich eines Tages möglichst kurz und am Ende des Tages ist.

Also statt
set HT.JOHN weekProfile Sat 16,09:00,19,22:00,16

nunmehr so
set HT.JOHN weekProfile Sat 16,09:00,19,22:00,16,23:55,16

John
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

Matthias Gehre

Scheint mir also ein Problem der Firmware der Heizthermostate zu sein und kein Problem der MAX FHEM Software.
Man könnte bei set HZ desiredTemperature auto natürlich das aktuelle Wochenprofil anschauen und dann intern
den Befehl in
set HZ desiredTemperature auto aktuelleWochenProfilTemperatur
umwandeln.
Wenn mir jemand dafür einen Patch schickt, dann check ich das ein.

John

Hallo Matthias,
besten Dank für deine Antwort.

ZitatScheint mir also ein Problem der Firmware der Heizthermostate zu sein und kein Problem der MAX FHEM Software.

Das wäre ein dramatischer Fehler des Herstellers, es würde bedeuten, dass der Sollwert im letzten Bereich eines Tages stets 17 Grad ausgibt,
unabhängig von den Vorgaben des Anwenders.
Der Fehler ist zu offensichtlich, als dass ein Profi diesen beim Testen übersehen könnte.


@Harald oder andere, die mit CUBE arbeiten
Kannst du bitte, über die original Max-Software das Wochenprofil in einem Thermostat erzeugen.
Danach sobald die aktuelle Zeit im letzten Bereich des Tagesprofils liegt via
set xy desiredTemperature auto

den Sollwert aus dem Wochenprofil einstellen und das Ergebnis mitteilen.

John

CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

Harald

Hallo John,

das habe ich doch oben schon berichtet. Das ist die gleiche Erscheinung, wie Du sie beschriebst.
Falls Dir das noch nicht genügt, sage was ich noch testen soll. Mache ich natürlich gerne.

Viele Grüße

Harald
Router:AVM7590 1&1 FW:FRITZ!OS 07.56 Anbindung:1&1 50/10 Mb/s, WLAN-Repeater 300E
ELV MAX!Cube, 7xThermostat, ECO, RasPi 4B mit bullseye auf Festplatte,
CUL V 1.67, JeeLink v3_10.1c, nanoCUL, 1xS300TH, 4xHMS100T, 4xELRO, 1xTFA, 2xMAX_FK
ELV MAX!1.4.5, FHEM 5.7 auf RasPi, Kostal PIKO plus

John

Hallo Harald,

ich dachte an einen Test komplett ohne FHEM also nur mit original MAX-Software.

Wir müssen ausschliessen, dass FHEM in irgend einer Weise Einfluss nimmt.

Verstehe ich dich richtig:

a. du hast das Wochenprofil mit original MAX-Software erstellt

b. beim letzten  Schaltpunkt setzt Max den Sollwert fest auf  17 Grad,
   obwohl du einen anderen Sollwert angegeben hast.

Das alles ohne jedes Zutun von FHEM, richtig ?


John
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

Harald

Ja, genauso, Lediglich das "set xy desiredTemperature auto" habe ich in FHEM gemacht, da es das in der Orinalsoftware nicht gibt. Das muss man dann am Ventil machen.

ZurSicherheit werde ich das nochmal testen. Ich melde mich dann.

Viele Grüße

Harald
Router:AVM7590 1&1 FW:FRITZ!OS 07.56 Anbindung:1&1 50/10 Mb/s, WLAN-Repeater 300E
ELV MAX!Cube, 7xThermostat, ECO, RasPi 4B mit bullseye auf Festplatte,
CUL V 1.67, JeeLink v3_10.1c, nanoCUL, 1xS300TH, 4xHMS100T, 4xELRO, 1xTFA, 2xMAX_FK
ELV MAX!1.4.5, FHEM 5.7 auf RasPi, Kostal PIKO plus

pet22

#8
Hallo John,

ich verfolge den Thread nun schon eine ganze Weile.

Zitata. du hast das Wochenprofil mit original MAX-Software erstellt

b. beim letzten  Schaltpunkt setzt Max den Sollwert fest auf  17 Grad,
   obwohl du einen anderen Sollwert angegeben hast.

Das alles ohne jedes Zutun von FHEM, richtig ?

Bestätigt für WT+ und allen bisherigen Cube FWs.
Bei der Kombination HT+ (FW laut FHEM: 1.0) mit WT (FW laut FHEM: 1.6) konnte ich das Verhalten mit den magischen 17 °C nicht beobachten (evtl. auch mangels Gelegenheit).

Bisherige Abhilfe seit Einführung von weekProfile: die factory default Schaltzeiten des Cube habe ich in mein individuelles FHEM weekProfile übernommen und zusätzliche individuelle Schaltzeiten/ Temperaturen integriert.
Es verblieb ein "Loch" zwischen 22:00 - 0:00. Wurde in dieser Zeit am WT+ HT+ zwischen manuell/ auto umgestellt erschienen die magischen 17 °C wieder, obwohl ein anderer Wert im weekProfile vorgegeben wurde.

Mit deinem Workaround verbleiben somit 5 Min in denen die 17 °C auftauchen könnten. Gestern ist es mir aber nicht gelungen den Effekt zu provozieren.

Vermutung: die FW des WT+ HT+ hat ein Problem mit dem Tages-/ Datumswechsel

Gruss

Pet22
Debian 11/ Intel Atom MB/ CUL V3/ Raspberrymatic/ Homematic classic, Homematic IP, WTs & HTs

John

Hallo pet22,

besten Dank für deine Rückmeldung.


John
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

Harald

#10
So, hier meine Ergebnisse:

Tagesprogramm in MAX! 3x je 16°C, Schaltzeit 2->3 jeweils angepasst, dass die Beobachtung der Umschaltung möglich

1. FHEM gestoppt, in Der MAX!-Übersicht kontinuierliche Anzeige 16°C Auto vor und nach der Schaltzeit
2. FHEM gestartet, MaxScan gestoppt, gleiches Verhalten von MAX!, auch nach "set xy desiredTemperature auto" von der WEB-Oberfläche
3. FHEM und MaxScan in Modus Sollwertänderung gestartet, gleiches Verhalten wie unter 2.
4. FHEM und MaxScan in Modus auto/manual- Umschaltung,  gleiches Verhalten wie unter 2.

Mir ist es nicht gelungen, ein Fehlverhalten zu provozieren !?!?

Viele Grüße

Harald
Router:AVM7590 1&1 FW:FRITZ!OS 07.56 Anbindung:1&1 50/10 Mb/s, WLAN-Repeater 300E
ELV MAX!Cube, 7xThermostat, ECO, RasPi 4B mit bullseye auf Festplatte,
CUL V 1.67, JeeLink v3_10.1c, nanoCUL, 1xS300TH, 4xHMS100T, 4xELRO, 1xTFA, 2xMAX_FK
ELV MAX!1.4.5, FHEM 5.7 auf RasPi, Kostal PIKO plus

pet22

Hallo Harald,

Zitatb. beim letzten  Schaltpunkt setzt Max den Sollwert fest auf  17 Grad,
   obwohl du einen anderen Sollwert angegeben hast.

Bei mir tritt dieser Effekt nicht genau nach dem letzten Schaltpunkt auf, sondern "irgendwann". Eine Systematik konnte ich in der bei mir konfigurierten Zeit von 2h nicht herausfinden.
Evtl. lässt auch bei dir der Effekt auch reproduzieren, wenn der WT(+) manuell auf "off" und dann nach ca. 10 min auf "auto" gestellt wird.

Gruss

Pet22
Debian 11/ Intel Atom MB/ CUL V3/ Raspberrymatic/ Homematic classic, Homematic IP, WTs & HTs

Harald

Tut mir leid, pet22, aber isch abe gar keinen WT!  ;) somit kann ich dazu auch nichts sagen. Meine obigen Tests sind deshalb auch alle ohne WT.

Viele Grüße

Harald
Router:AVM7590 1&1 FW:FRITZ!OS 07.56 Anbindung:1&1 50/10 Mb/s, WLAN-Repeater 300E
ELV MAX!Cube, 7xThermostat, ECO, RasPi 4B mit bullseye auf Festplatte,
CUL V 1.67, JeeLink v3_10.1c, nanoCUL, 1xS300TH, 4xHMS100T, 4xELRO, 1xTFA, 2xMAX_FK
ELV MAX!1.4.5, FHEM 5.7 auf RasPi, Kostal PIKO plus

pet22

#13
sorry - ich meinte HT+  :-[

Beitrag in der Zwischenzeit korrigiert

Gruss

Pet22
Debian 11/ Intel Atom MB/ CUL V3/ Raspberrymatic/ Homematic classic, Homematic IP, WTs & HTs

John

#14
Ich habe nun noch einen OFFLINE-Versuch mit meinem HT+ Thermostat durchgeführt.

FactoryReset am Thermostat.
Wochenprofile eingestellt.

Im letzten Bereich des Tages schaltet das Thermostat korrekt auf den eingestellten Sollwert.
Der beobachtet Fehler ist unter diesen Bedingungen nicht reproduzierbar.

Es ist also kein systematischer Fehler in der Firmware des Thermostats.

Der Zeitbereich eines Schaltpunktes lässt sich im 5- Minuten-Raster einstellen.

Lediglich die Endzeit des Tages lässt sich auf 23:59 einstellen.

Sobald das Thermostat angelernt wird, scheint es sein Wochenprofil auf die FactoryReset-Einstellung zurückzusetzen.
Laut FHEM Protokoll, wird hierbei vom Thermostat das Wochenprofil an FHEM übertragen.
Damit kann man leider die zuvor eingestellten Werte des Wochenprofils nicht mehr nachvollziehen.

Folgende Fragen:

Was sendet das WT an das Thermostat, wenn man dort das Wochenprofil ändert ?
Kann man dies aufzeichnen ?
Wenn ja, wie ?

Weiterhin müsste sich noch jemand finden der über die nötigen Komponenten verfügt und die Aufzeichnung zur Verfügung stellt.

John



CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

Matthias Gehre

Was sendet das WT an das Thermostat, wenn man dort das Wochenprofil ändert ?
- Ich kanns nicht testen, aber es würde mich wundern, wenn das WT etwas an das HT sendet. Wahrscheinlich muss man das ConfigWeekProfile mit einem bestimmten Flag + groupId senden, sodass alle HT's das mitlesen. Das tut der aktuelle Code aber nicht; vielleicht kann jemand testen, ob eine Änderung hier abhilfe bringt. Details: groupId => sprintf("%02x",$groupid), flags => ( $groupid ? "04" : "00" ) muss zum Aufruf von ($hash->{IODev}{Send})->($hash->{IODev},"ConfigWeekProfile",..) hinzufügen. Siehe den Aufruf für "SetTemperature".

Kann man dies aufzeichnen ?
Wenn ja, wie ?
- Alle Kommunikation der MAX-Komponenten wird über den CUL mitgeschnitten und taucht im Log auf.

John

Also suchen wir jemanden, der seine MAXe/WTs über einen CUL ansteuert und mit dem WT zusammen eine Raulösung mit mindestens 2 Thermostaten bedient.

Bitte melden, wer diese Voraussetzungen erfüllt.

John
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

cotecmania

Habe im Wohnzimmer 1 WT und 2 MAXe, allerdings habe ich gerade Probleme, diese wieder zu pairen, nachdem meine Kids den WT "abgeschossen" haben und die Batterien rausfielen.

Ein associate bringt seit ner halben Stunde nur fehlende Credits ;-((

2013.12.16 20:56:14 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 1, but we need 110. Waiting 109 seconds.
2013.12.16 20:58:05 1: Device HK_WOHNEN answered with: Invalid command/argument
2013.12.16 20:58:05 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 2, but we need 110. Waiting 108 seconds.
2013.12.16 20:59:54 1: Device HK_WOHNEN answered with: Invalid command/argument
2013.12.16 20:59:54 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 1, but we need 110. Waiting 109 seconds.
2013.12.16 21:01:45 1: Device HK_WOHNEN answered with: Invalid command/argument
2013.12.16 21:01:45 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 2, but we need 110. Waiting 108 seconds.
2013.12.16 21:03:34 1: Device HK_WOHNEN answered with: Invalid command/argument
2013.12.16 21:03:35 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 1, but we need 113. Waiting 112 seconds.
2013.12.16 21:05:28 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 2, but we need 110. Waiting 108 seconds.
2013.12.16 21:07:17 1: Device HK_WOHNEN answered with: Invalid command/argument
2013.12.16 21:07:18 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 1, but we need 110. Waiting 109 seconds.
2013.12.16 21:09:08 1: Device HK_WOHNEN answered with: Invalid command/argument
2013.12.16 21:09:08 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 1, but we need 110. Waiting 109 seconds.
FHEM auf RaspberryPI B (buster)
2xCUL868 für MAX/Slow_RF, HM-LAN, JeeLink
MAX!/HM-Thermostate, FS20/HM-Rolladenschalter, FS20-EM, LevelJet-Ölstandsmessung, PCA301, IT, KM271, IPCAM, FireTAB10 FTUI

Stephan

#18
Ich habe diesen 17 Grad Fehler auch und zwar sowohl am HT+ als auch am HT. Ich habe das mangels Kenntnis diesen Threads im maxscanner thread beschrieben. Sowohl HT+ als auch HT ohne WT.
Den Effekt mit den stundenlangen nocredits habe ich ebenfalls. Ein deaktivieren des scanners ändert nichts.
Meine wochenprofile bestehen aus nur einem  Schaltpunkt pro Tag.
Ich kann mich nicht erinnern, dieses verhalten früher beobachtet zu haben.

Gruss
Stephan
   

Gruß
Stephan

fhem 5.5, Raspi B, CUL V3 868 (max), Arduino Uno R3 conf.firmata v2.05

Stephan

Vielleicht sollte ich noch dazu sagen, das ich ebenfalls seit kurzem den Effekt habe, das die wochenprofile aus den readings verschwinden und wenn man einen tag neu eingibt, ist das gesamte profil wieder da.
Wann wo und wie das auftritt, das habe ich noch nicht ergründet.

Gruss
Stephan
   
Gruß
Stephan

fhem 5.5, Raspi B, CUL V3 868 (max), Arduino Uno R3 conf.firmata v2.05

Bonzon

Hallo zusammen,

da ich seit kurzen wiedereinmal das selbe Problem habe, melde ich mich hier ebenfalls zu Wort ( und weil mich John dazu drängt, womit er ja recht hat ;) )

Stand der aktuellen Dinge.

Ich habe 3 HT+. Alle 3 habe ich resettet und neu mit dem FHEM gepaired. Anschließend habe ich allen 3 HTs das selbe Wochenprofil gegeben

set HT_.* weekProfile Mon 17 Tue 17 Wed 17 Thu 17 Fri 17 Sat 17 Sun 17

Das haben auch alle verstanden und in ihren Readings stehen.  Alle 3 HTs laufne mit dem maxScanner.

Jetzt das Problem. 2 der 3 HTs laufen jetzt ununterbrochen auch 17°C und regeln sich gar nicht. Lediglich das HT im Wohnzimmer hat sich um 17 Uhr auf 21°C geregelt und um 23 Uhr auf 17°C zurück. Heute um 6 Uhr regelte er sich wieder auf 21 °C und um 9 Uhr wieder zurück auf 17 °C.

Nun mein Versuchsaufbau:

1. HT im Wohnzimmer (HT mit kuriosem Verhalten) - Temperatur: 17°C - mode: auto -  kein MaxScanner aktiv
2. HT im Badezimmer - Temperatur manuell auf 21 °C - mode: manual - kein MaxScanner aktiv
3. HT im Arbeitszimmer - Temperatur manuell auf 21 °C - mode: auto - MaxScanner aktiv

Dies konstellation läuft nun seit heute morgen um 10 Uhr und bisher hat sich keine Veränderung eingestellt. Ich vermute einmal das sich eine erste Veränderung gegen 17 Uhr am HT im Wohnzimmer ankündigt.

An der Stelle hätte ich noch zwei Fragen.

Wenn im FHEM die readings für ein Thermostat ( zum Beispiel das weekProfile ) auftauchen, heißt das dann auch, dass das HT diese Einstellung auch hat?
Wie sieht eigentliche das default Weekprofile nach dem factoryReset aus?

Stan
Raspberry Pi Typ B, 512 MB mit CUL V3.4 (Firmware 1.57 CUL868) für Homatic und CUL V3.4 (Firmware 1.57 CUL868) für MAX!
MAX!: Heizkörperthermostate, Wandthermostat WT+
Homatic: HM-LC-SW1-FM
Netatmo Wetterstation: Indoor-Modul, Outdoor-Modul

Bonzon

So aktueller Stand: 17:40 Uhr

1. HT im Wohnzimmer (HT mit kuriosem Verhalten) - Temperatur: von 17°C auf 21 °C - mode: auto -  kein MaxScanner aktiv (Veränderte sich, außerhalb des Wochenprofiles)
2. HT im Badezimmer - Temperatur manuell auf 21 °C - mode: manual - kein MaxScanner aktiv (keine Änderung aufzuweisen)
3. HT im Arbeitszimmer - Temperatur manuell auf 21 °C - mode: auto - MaxScanner aktiv (keine Änderung aufzweisen)


weekprofile-0-Sat-temp 17.0 °C 2014-02-04 19:44:12
weekprofile-0-Sat-time 00:00-00:00 2014-02-04 19:44:12
weekprofile-1-Sun-temp 17.0 °C 2014-02-04 19:44:12
weekprofile-1-Sun-time 00:00-00:00 2014-02-04 19:44:12
weekprofile-2-Mon-temp 17.0 °C 2014-02-04 19:44:12
weekprofile-2-Mon-time 00:00-00:00 2014-02-04 19:44:12
weekprofile-3-Tue-temp 17.0 °C 2014-02-04 19:44:12
weekprofile-3-Tue-time 00:00-00:00 2014-02-04 19:44:12
weekprofile-4-Wed-temp 17.0 °C 2014-02-04 19:44:12
weekprofile-4-Wed-time 00:00-00:00 2014-02-04 19:44:12
weekprofile-5-Thu-temp 17.0 °C 2014-02-04 19:44:12
weekprofile-5-Thu-time 00:00-00:00 2014-02-04 19:44:12
weekprofile-6-Fri-temp 17.0 °C 2014-02-04 19:44:12
weekprofile-6-Fri-time 00:00-00:00 2014-02-04 19:44:12


So sehen die Readings zum weekProfile aus. Ohne Workaround von John.

Ich lasse die Thermostate jetzt einmal laufen, in der Hoffnung einen komplett sauberen Log zu bekommen.

Vielleicht hat jemand eine Idee.
Raspberry Pi Typ B, 512 MB mit CUL V3.4 (Firmware 1.57 CUL868) für Homatic und CUL V3.4 (Firmware 1.57 CUL868) für MAX!
MAX!: Heizkörperthermostate, Wandthermostat WT+
Homatic: HM-LC-SW1-FM
Netatmo Wetterstation: Indoor-Modul, Outdoor-Modul

Stephan

Du solltest in jedem Fall um 23:55 Uhr noch einen Wert eintragen. Kann ruhig der gleiche wie vorher sein.
also

set HT_.* weekProfile Mon 17,23:55,17 Tue 17,23:55,17 Wed 17,23:55,17 Thu 17,23:55,17 Fri 17,23:55,17 Sat 17,23:55,17 Sun 17,23:55,17
Gruß
Stephan

fhem 5.5, Raspi B, CUL V3 868 (max), Arduino Uno R3 conf.firmata v2.05

tuxbox

#23
Die 17 °C sind ein Fallback (Profil) der Firmware. Im üblichen Setup muss das Profil zusammen mit der raumid (bei fhem wohl groupid) übertragen werden, und zwar nur an das WT wenn vorhanden (alle HT natürlich in der gleichen groupid != 0 wie das WT) . Code siehe oben von Matthias.
BTW muss das auch bei der Übertragung u.a. der Boost-Parameter passieren (sonst löst zB zwar das WT auch beim HT ein boost aus wenn assoziiert, aber letztlich mit den Einstellungen im HT).
Beim Wochenprofil ist es ähnlich.  Zwar wird wegen der Assoziation die Temperatur am HT nachgezogen und der Mode richtig angezeigt,  aber es gibt dann zb nach dem Fensteröffnen erstmal einen Rücksprung in das Profil vom HT.
Auch gibt es unnötige zusätzliche Funktelegramme für die ständigen Korrekturen bzw das Nachziehen (, wenn nicht jeder Raum/Gruppe seine groupid hat und die auch beim senden des Profils (und 4er flag für raum statt id addressierung) mit gegeben wird.

Beim erzeugten Profilkommando legt das MAX modul offenbar für den letzten Kontrollpunkt leider eine "0-Zeit" an. Das ist eigentlich imho nicht gültig.  Der letzte Kontrollpunkt muss 23:55 sein.
Wenn man den Punkt zufällig belegt ignoriert die Firmware den ungültigen Rest immerhin.

Wenn man obiges alles berücksichtigt, sollte alles wie gewünscht hinhauen. ;-)

PS: bei Gelegenheit verfasse ich mal einen Wiki Artikel zu diesem und anderen Zusammenhängen, die noch etwas Nachbesserung bräuchten.



Ralf.E

Moin,

dieser Thread ist schon etwas älter, scheint mir aber recht gut zu passen - ich denke das Thema ist immer noch aktuell? Zumindest lassen neuere Threads darauf schliessen (z.B. http://forum.fhem.de/index.php/topic,48657.0.html).

Wäre vielleicht mal ein Sticky-Thread wert...

Nach der Migration von MAX-Cube/-Software (ca. 3 Jahre verwendet) nach CUL/Fhem bin ich jetzt auch in diese Herausforderung gelaufen, obwohl es im Wiki erwähnt wird. Ich kann mich allerdings nicht daran erinnern das 17°C-Problem vor der Migration gesehen zu haben?!?

Der MAX-Cube war vor der Migration via MAXLAN eingebunden. Ich habe mir die von Fhem angezeigten Einstellungen notiert und in die Fhem weekprofiles übernommen. Das 17°C-Problem konnte ich jetzt in 2 Konstellationen nachvollziehen:

Konstellation 1: 3x HT, FK und WT - letzte Schaltzeit war bisher um 23:00 auf 19°C:
- Fenster nach 23:00 öffnen und schliessen => 17°C
- HT erreicht den 23:00 Uhr Schaltpunkt => alle WT's auf 17°C
- 'set desiredTemperature auto' => alle WT's auf 17°C

Konstellation 2: 1x HT+ und FK - letzte Schaltzeit war bisher um 23:00 auf 20°C:
- HT erreicht Schaltzeit => 20°C
- Fenster nach 23:00 öffnen und schliessen => 17°C

Liegt für mich die Vermutung nahe, dass nur "externe" Ereignisse wie 'Fenster öffnen/schliessen' und 'set desiredTemperature auto' (WT oder Fhem) den HT dazu veranlassen auf 17° umzustellen (letzter Zeitschaltpunkt des Tages bereits erreicht).

Also habe ich den hier vorgeschlagenen workaround umgesetzt. Bei der Kombination HT's + WT sollten die Wochenprofile in den WT und die HT's übertragen werden! Fenster öffnen und schliessen führt sonst im HT wieder zu 17°C - habe aber (noch) nicht geprüft, ob der WT das zeitverzögert wieder korrigiert...

Gruß Ralf
Rpi4> FHEM, TabletUI, Z-Wave, EnOcean, Hue, HmIP via Debmatic

janvonnebenan

#25
Hallo,

ich habe mir das mal angesehen. Es ist doch so, dass ein Wochenplan ohne den zusätzlichen Schaltpunkt kurz vor Ende des Tages linear funktioniert. Der Thermostat kann ihn also von links nach rechts lesen und findet die nächste Temperatur. Schließt man allerdings nach dem letzten Schaltpunkt beispielsweise ein Fenster, so findet er die Temperatur seines letzten Schaltpunktes nicht und wechselt auf den Wert 17 Grad. Mir ist außerdem aufgefallen, dass in der Originalsoftware der letzte Zeitpunkt nicht mit "00:00" Uhr sondern mit "24:00" Uhr bezeichnet wird. Ich habe mal die "10_MAX.pm" dahingehend verändert und nach einem Tag des Testens, würde ich sagen, dass es funktioniert. Hier mal meine Änderungen:

Ab Zeile 507:

if($j + 1 == @controlpoints) {
  $hour = 24; $min = 00;
} else {
  ($hour, $min) = ($controlpoints[$j+1] =~ /^(\d{1,2}):(\d{1,2})$/);
}


Zeile 513:

return "Invalid time: $controlpoints[$j+1]" if(!defined($hour) || !defined($min) || $hour > 24 || $min > 59);


Es wird aber dennoch "0:0" im Thermostat abgelegt oder das CUL macht das, deshalb ab Zeile 223:

if(int($hours[$j])==0 && int($minutes[$j])==0){
  $hours[$j]=24;
   last;
}


Ich bin wirklich nicht vertraut mit dem Code von FHEM und habe nur ganz wenig Erfahrung mit Perl, deshalb under Vorbehalt. Vielleicht kann das ja mal jemand, der das wirklich versteht überprüfen. Getestet habe ich mit CUL_MAX und mehreren Thermostaten und einem Raumthermostat. Als Anhang übersende ich mal die komplette Datei.

Herzliche Grüße
Jan

janvonnebenan

Ich habe Zeile 513 nochmal verändert, damit man für die Zeit nicht 24:01 ... 24:59 eingeben kann:

return "Invalid time: $controlpoints[$j+1]" if(!defined($hour) || !defined($min) || $hour>24 || $min>59 || ($hour==24 && $min>0));


Jan

christiang

#27
Hab die veränderte File von dir jetzt auch heruntergeladen und teste damit. Bis jetzt schauts gut aus!

Gruß Christian

janvonnebenan

Danke! das ist super. Ich habe bis jetzt noch keine Probleme feststellen können. Ich benutze übrigens zusätzlich das Modul Weekprofile. Dort ist das Ende des Tages ebenfalls mit 24:00 Uhr bezeichnet.

Herzliche Grüße
Jan

justme75

Moin moin,
ich bin ebenfalls ein vom dem 17°-Problem geplager MAX-User - ich wollte mal fragen, ob Du Deinen Patch auch dem Maintainer von MAX geben willst? Für mich klingt's ja so als wäre das eine wünschenwerte Änderung...

lg, justme

janvonnebenan

#30
Moin Justme,

ja das ist geplant. Allerdings habe ich gerade extrem wenig Zeit. Hast du den Patch bei dir auch erfolgreich ausprobiert. Das würde mich ja brennend interessieren.

Patchen geht übrigens so:

sudo patch -p1 /opt/fhem/FHEM/10_MAX.pm < ./fix_weekprofile_bug.patch


Das muss man dann aber nach jedem Update erneut durchführen.

Herzliche Grüße
Jan

Shardan

#31
Hallo zusammen,

bei mir tritt ebenfalls ein 17°-Problem auf.
Aufgefallen ist mir das bei dem Versuch, die Heizkörperthermostate per "Presence" zu steuern.

set MAX_xxxxxx desiredTemperature eco"
funktioniert einwandfrei, wenn presence auf "absent" geht.

Umgekehrt geht das nicht:
set MAX_xxxxxx desiredTemperature auto
steuert einen der Thermostate wieder ins Wochenprogramm, alle anderen gehen auf 17°....

Kann man das irgendwie beheben?

Shardan


Edit:
Ich hab den Patch grade eingespielt, der hilft leider nicht weiter.
Möglicherweise ein Problem einer bestimmten Firmware-Version?
Der eine Tehrmostat, der funktioniert, ist neuere als die anderen.
S.
FHEM auf Celeron-PC
CUNX mit Pigator, 433 + 868 MHZ.
MAX!-HK-Ventile, ESP8266-Sensoren und -Aktoren
Schaltsteckdosen IT / NetIO230B / Netio4

justme75

Moin moin,

Zitat von: janvonnebenan am 25 Februar 2017, 08:19:52
Moin Justme,

ja das ist geplant. Allerdings habe ich gerade extrem wenig Zeit. Hast du den Patch bei dir auch erfolgreich ausprobiert. Das würde mich ja brennend interessieren.

Patchen geht übrigens so:

sudo patch -p1 /opt/fhem/FHEM/10_MAX.pm < ./fix_weekprofile_bug.patch


Das muss man dann aber nach jedem Update erneut durchführen.

Herzliche Grüße
Jan

Ich hab es bisher noch nicht bei mir ausprobiert, weil ich im Moment nur am Wochenende zu Hause bin (Grund für die Einrichtung von FHEM) und nach dem letzten Update offenbar ein Problem mit weekprofile habe, was ich gerade versuche zu debuggen - das hätte ich gerne zuerst gelöst.
Wie man patcht weiß ich, danke :-) (zumindest unter unixoidem OS - hier hätte ich mit Windows mangels jeglicher Erfahrung seit Win98SE größere Probleme).

So wie das klingt wärst Du ja über eine größere Testtiefe nicht unglücklich - dann werd ich mal versuchen, ob ich da am WE weiterkomme und den Patch einbauen, wenn alles andere läuft.

lg,
justme

justme75

Moin moin,

Zitat von: janvonnebenan am 25 Februar 2017, 08:19:52
Moin Justme,

ja das ist geplant. Allerdings habe ich gerade extrem wenig Zeit. Hast du den Patch bei dir auch erfolgreich ausprobiert. Das würde mich ja brennend interessieren.


so, seit gestern läuft ein gepatchtes 10_MAX.pm auch bei mir - funktionieren tut es schon mal.
Was mir aufgefallen ist: ich verwende weekprofile mit useTopics=1, übermittle also im Normalfall neue/geänderte Einstellungen mittel restore_topic an die Thermostate.
Nachdem ich gestern fhem mit dem gepatchten MAX-Modul neu gestartet habe habe ich die bisher in allen Profilen an allen Tagen liegende 23:55-Einstellung entfernt und die geänderten Profile an die Thermostate geschickt - dabei zeigten meine beiden Wandthermostate das äußerst merkwürdige Verhalten, daß trotz des lt. Reading korrekt übermittelten Profils diese auf eine nirgends in ihrem Profil vorhandene tiefere Temperatur (einer auf 8°C und der andere auf 12°C)  als Sollwert sprangen (und auch die jeweils verbundenen Heizkörper entsprechend abregelten) - wieder auf den korrekten Wert ließen sie sich setzen, indem ich einmal die Modes von Auto über Man und Urlaub zurück auf Auto durchgetoggelt habe. Die beiden Räume, in denen nur Heizkörperthermostate verbaut sind zeigten ein derartiges Verhalten nicht, und mit dem originalem MAX-Code habe ich sowas auch noch nie gesehen. Ich werd das Ganze erstmal etwas weiter beobachten...

lg, justme

magenbrot

kurze Frage: Funktioniert das mit dem Patch jetzt korrekt? Ich habe immer noch den Workaround drin und wüsste gern ob der noch nötig ist.

syntysycer

Hi Jungs,

kann den Patch jemand einpflegen ...


stefanru

Hi,

habe auch das 17 Grad problem.
Teste auch den Patch...

Gruß,
Stefan

jlp2097

Habe bei mir den Patch seit 1,5 Wochen am Laufen (MAX-Elemente bei mir: Thermostate, Fensterkontakte) und hab seitdem kein Problem mehr mit den 17 Grad.

Kann den Patch jemand bitte einchecken?
Raspi mit CUL V3
Max:Thermostat+, Wandthermostat+, Fensterkontakte
Homematic: HM-LGW-O-TW-W-EU-2, HM-Sec-RHS, Funkschaltaktor mit Sirene, Fensterkontakte
Sonstiges: Viessmann via VControld und Optolink, Sensoren DS18B20, DHT11, Reedkontakte, BME680, viele diverse Shellys, diverse sonstige

kingmathers

Ich verwende den Patch auch schon seit Monaten und würde mich übers einchecken freuen :)
Raspberry Pi B+, FS20, 1-Wire, HM
FHEM Home Control (App für Windows 10): https://forum.fhem.de/index.php/topic,49891.0.html
FHEM Arduino Library: https://forum.fhem.de/index.php/topic,94093.0.html

Johnnyflash

Zitat von: Matthias Gehre am 14 Dezember 2013, 22:46:25
Was sendet das WT an das Thermostat, wenn man dort das Wochenprofil ändert ?
- Ich kanns nicht testen, aber es würde mich wundern, wenn das WT etwas an das HT sendet. Wahrscheinlich muss man das ConfigWeekProfile mit einem bestimmten Flag + groupId senden, sodass alle HT's das mitlesen. Das tut der aktuelle Code aber nicht; vielleicht kann jemand testen, ob eine Änderung hier abhilfe bringt. Details: groupId => sprintf("%02x",$groupid), flags => ( $groupid ? "04" : "00" ) muss zum Aufruf von ($hash->{IODev}{Send})->($hash->{IODev},"ConfigWeekProfile",..) hinzufügen. Siehe den Aufruf für "SetTemperature".

Kann man dies aufzeichnen ?
Wenn ja, wie ?
- Alle Kommunikation der MAX-Komponenten wird über den CUL mitgeschnitten und taucht im Log auf.

Hallo,
auch wenn das hier schon einige Zeit her ist: Ich habe die vorgeschlagenen Änderungen im Code umgesetzt. Die groupid wird jetzt sowohl beim Setzen des weekprofiles als auch bei den boost-Parametern mit übertragen. Das funktioniert sehr gut! Egal ob ich das weekprofile an das Wandthermostat oder an das Heizkörperthermostat übertrage, beide laufen danach mit dem neuen weekprofile!
Eine Sache ist mir dabei noch aufgefallen. Jedes mal wenn ich den Button fürs pairing am WT oder HT betätige, wird die groupid auf 0 gesetzt! Die Thermostate haben ihre groupid allerdings noch korrekt gespeichert! Wenn ich nämlich händisch über setreading (was ja definitiv die groupid nicht erneut sendet) die groupid korrigiere, werden die Parameter wieder korrekt an beide Geräte einer Gruppe übertragen. Ich vermute daher einen Fehler beim zurücklesen der Informationen aus dem WT/HT, oder die Geräte übertragen diese Informationen bereits falsch. Ich habe den Code allerdings noch nicht komplett verstanden und konnte das daher noch nicht näher eingrenzen. Ich werde aber mal weiter forschen...

swsmily

Ich habe den Thread jetzt nur überflogen.
Mein Cube hat vor kurzem (zum Glück, als es bereits warm war) alles vergessen.
Ich habe 3 Thermostate, diese alle neu angelernt an den Cube (Windows-Software). Da dadurch alle Wochenprofile weg waren, die ich bisher immer über die Software eingestellt hatte, habe ich für die 3 Thermostate weekprofile angelegt.
Nun habe ich auch das Problem sobald ich die Thermostate auf Auto schalte, dass diese nur auf 17 Grad stellen.
Keine Ahnung ob es an WeekProfile wirklich liegt, früher hatte ich dies jedoch nicht verwendet und durch Zufall diesen Thread hier gefunden.

Ist dieser Patch der hier erwähnt wird unterdessen über die Update-Funktion von FHEM eingespielt?


Habe nun Testweise bei einem Thermostat über die MAX-Software alles auf 21 Grad eingestellt und dann in FHEM den Auto-Modus gesetzt. FHEM und auch die Software zeigen mir nun 21 Grad an - weitere Tests konnte ich dank des Duty-Cycle nicht mehr durchführen (vorher an allen 3 Thermostaten probiert) - aber es sieht so aus, dass über die Software eingestelltes Wochenprogramm funktioniert, nur über Weekprofile nicht.

swsmily

Ich habe in den letzten Tagen weiter getestet (mit allen originalen Dateien die über update kommen).

Mir ist dabei nun aufgefallen, ändere ich über die offizielle MAX!-Software den Wochenplan, werden die richtigen Temperaturen eingestellt beim Wechseln von OFF zu AUTO.
Sende ich den Wochenplan von Weekprofile zu einem Thermostat, stellt sich das Thermostat immer auf 17 Grad beim WEchseln von OFF zu AUTO.
Schade - so ist Weekprofile nicht nutztbar.
Den Patch hier hab ich irgendwie nicht eingespielt bekommen, oder hat bei mir nicht funktioniert.


dennisk

Ich würde gerne auch noch einmal nachfragen, ob der Patch nicht doch noch übernommen werden könnte?
Der letzte commit stammt von @rudolfkoenig, der das vielleicht übernehmen kann?

Vielen Dank schon mal!

D3ltorohd

Kann man das WeekProfile auch ganz raus nehmen ? Und sich da was mit Doifs basteln ?
Base : Intel NUC Debian 9, FHEM aktuell || Zigbee (Coordinator FW Z-Stack 1.2 default Koenkk) || MaxCUL (culfw V 1.67 nanoCUL868) || SIGNALduino 433MHz (V 3.3.2.1-rc8 ) || Shelly s1

rudolfkoenig

Habe den Patch eingecheckt.
Sorry fuer die spaete Reaktion, ich verdraenge immer wieder erfolgreich, dass ich kommissarisch fuer das Modul zustaendig bin.
Falls jemand das Modul uebernehmen will, bitte melden.

D3ltorohd

Zitat von: rudolfkoenig am 01 November 2019, 09:27:16
Habe den Patch eingecheckt.
Sorry fuer die spaete Reaktion, ich verdraenge immer wieder erfolgreich, dass ich kommissarisch fuer das Modul zustaendig bin.
Falls jemand das Modul uebernehmen will, bitte melden.

Somit sollte das Problem behoben sein und man muss am Ende des Tages keine Schaltzeit um 23:55 mehr mit einbauen ?
Base : Intel NUC Debian 9, FHEM aktuell || Zigbee (Coordinator FW Z-Stack 1.2 default Koenkk) || MaxCUL (culfw V 1.67 nanoCUL868) || SIGNALduino 433MHz (V 3.3.2.1-rc8 ) || Shelly s1

dennisk

@rudolfkoenig vielen Dank!

Bei meinen Thermostaten kann ich mit dem Patch jedenfalls keine Probleme feststellen. Und ich habe keine extra Schaltzeitpunkte kurz vor Mitternacht eingerichtet.

mickym

#47
So ich melde nun auch mal Interesse an dem Patch an.

Der Thread ist zwar schon ewig alt und ich habe aber auch das 17°C Problem. Ich bin erst gar nicht auf die Idee gekommen, dass dieses Problem immer noch existiert.

Trotz Patch mal zur Info - wie ich mir bislang geholfen habe:
Ausgangszustand:
Ich habe die Profile über FHEM gesetzt - dann 17°C Problem, wenn man auf AUTO umschaltet - egal welche Temperatur im Wochenprofil aktiv war.
In der MAX-Software wurden korrekt die Wochenprofile angezeigt, die über FHEM gesetzt wurden, aber beim Schalten auf AUTO egal, ob am Gerät direkt oder auch der MAX Software - AUTO ist immer 17°C.
Habe dann das Gerät mit der MAX Software aus dem CUBE gelöscht - und dann wieder mit dem CUBE gekoppelt. Beim erneuten Verbinden des Wandthermostats oder des Heizkörperthermostats wurden dann die korrekten Profile übernommen (ohne dass ich noch eine Zeit kurz vor Mitternacht eingetragen habe).


Johnnyflash

Hallo,
ich habe auch noch einige Änderungen an der 10_MAX.pm vollzogen. Grund dafür war, dass gewissen Daten (WeekProfile, Boost-Dauer, Boost-ValvePosition, etc) in einem Raum sowohl an das Wandthermostat als auch an die Ventile geschickt werden müssen. Dies wird über die GroupID gelöst. Wer möchte, kann das ja mal mit angehängter Version testen, bevor der Patch eingecheckt wird.
To Do ist allerdings noch, dass die entsprechenden Readings bei allen Geräten mit gleicher GroupID geändert werden müssen. Weiterhin ist das Problem noch nicht gelöst, dass die GroupID regelmäßig auf 0 zurückgesetzt wird.

mickym

#49
Die group-ID bleibt bei mir erhalten - aber ich habe auch noch zusätzlich die Verbindung zu ELV Portal offen - da mir der Cube sonst die Konfig irgendwie vergisst. Mit der Verbindung bleibt aber die group ID erhalten. Ich habe bis jetzt halt die weekProfiles immer an den Wandthermostat und an die Heizkörperthermostate geschickt.

Der Patch scheint aber Fehler bei der Definition dieser Group-ID zu haben. Ich schick mal das LOG mit. Ich hoffe, ich hab mir sonst nichts zerschossen. ;)

Nachtrag:
Ich habe mir bislang bei Änderungen am Wochenprofil oder ähnlichen Einstellungen angewöhnt, dass in der Regel in einem Raum immer an den Wandthermostat und an den Heizkörperthermostat zu schicken, damit keine Inkonsistenzen entstehen.
Ohne es belegen zu können, habe ich generell den Verdacht, dass auf den MAX-Portalen irgendwelche Konfigeinstellungen gespeichert werden. Ich hatte das Portal mal für ein paar Wochen abgeklemmt, da ich dachte, dass ich das ja nun nicht mehr brauche, das lief auch alles, bis ich den Cube mal für mehrere Stunden stromlos machen musste. Danach musste ich jedes Gerät neu anlernen. FHEM hat zwar eine Verbindung zum CUBE aufgebaut, konnte aber auch keine Geräte mehr finden.

Johnnyflash

Zitat von: mickym am 06 November 2019, 10:24:08
Der Patch scheint aber Fehler bei der Definition dieser Group-ID zu haben. Ich schick mal das LOG mit. Ich hoffe, ich hab mir sonst nichts zerschossen. ;)
Mein Fehler, hatte ein paar Änderungen rausgenommen, weil sie nur zum testen drin waren. Dabei habe ich ein paar Zeilen zu viel entfernt. Hier die korrigierte Variante.
Zitat von: mickym am 06 November 2019, 10:24:08
Ich habe mir bislang bei Änderungen am Wochenprofil oder ähnlichen Einstellungen angewöhnt, dass in der Regel in einem Raum immer an den Wandthermostat und an den Heizkörperthermostat zu schicken, damit keine Inkonsistenzen entstehen.
Genau das möchte ich vermeiden, ich komme damit schnell an die Credit-Grenze in meiner Installation (Habe 16 Heizkörperthermostate und 14 Wandthermostate im Einsatz). Die Original Max Software im Cube arbeitet höchstwahrscheinlich genau so, dass über die GroupID die entsprechenden Parameter an alle Komponenten eines Raumes geschickt werden. Wollte das immer mal analysieren, habe aber keine Cube hier.

Johnnyflash

Irgendwas scheint da mit meiner Änderung aber noch nicht ganz zu stimmen. Habe mir heute mal einen cube geliehen, der Cube schickt die Broadcast Nachrichten pro Raum mit dem Flag 05, nicht 04. Hat eigentlich irgendjemand eine Protokollbeschreibung zum MAX! Funkprotokoll? Ich finde nur was zum LAN Protokoll des Cubes.