Fehler im Weekprofile

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

Vorheriges Thema - Nächstes Thema

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