[Testversion] Heating_Control=>WeekdayTimer

[Beta-User]

So haben dann auch mal von Heat Control umgestellt bis jetzt sieht alles gut aus.

Danke für die Rückmeldung und das Testen!

Gehe ich recht in der Annahme, dass du einfach die Module genommen hast, die am WE über das update verteilt wurden, und FHEM auch ansonsten diesem Stand entspricht?

Bin mal gespannt, was ToKa rückmeldet, wo die diversen Schwierigkeiten bei ihm im einzelnen herkamen.

[majestro84]

Genau habe heute ein Thema Update mit den Modulen gemacht und alles mit diesen Versionen getestet

[ToKa]

Hallo Beta-User,

Klingt danach, als wären es die Testersionen gewesen iVm. einem älteren FHEM? (Das FUUID noch nicht kennt, weswegen statt der FUUID in dem RAW-Array das erste Attribut rausgeworfen wird).

fhem war aktuell (Update 11.05.2019) als ich gestern dann das Update und die Umstellung auf das neue WeekdayTimer gemacht habe. Meine Geräte hatten alle eine FUUID.

Danke für den Hinweis; läßt sich vermutlich auch nicht vollständig abfangen, wenn z.B. der Modultyp mit abgefragt wird oder das anders benannte Attribut.

Hatte weder den Modultyp noch den Alias in der RG, aber vielleicht bentuzt RG das ja intern.

Hmm, bist du sicher, dass das auf die Umstellung zurückzuführen ist, un dnicht z.B. auf einen update der Perl-Version? An sich hat HC intern eigentlich nur Funktionen aus WDT verwendet und (fast) alles war ansonsten gleich. Wenn es das mit dem Perl-update nicht ist, muß ich mir das mal ansehen...

Schwer zu sagen, da ich mir das stateFormat schon lange nicht mehr angeschaut habe, da die Geräte über die RG dargestellt werden. Ein Perl-Update habe ich zumindest nicht bewusst gemacht oder mitbekommen, dass es auf meinem PI eines gegeben hätte. Aktuell handelt es sich um die Version: This is perl 5, version 24, subversion 1 (v5.24.1). Ich habe nun nach dem Fehler gegoogelt und es gab sogar einen Treffer hier im Forum. Es lag an den doppelten ;; bzw. den \. Nachdem ich diese entfernt habe, ist das stateformat wieder ok.

Funktional konnte ich bislang keinen Unterschied oder gar Fehler feststellen.

Beste Grüße
Torsten

[Beta-User]

Moin ToKa,

Danke für die Rückmeldungen, wegen des Verlusts des alias-Attributs muß ich wohl nochmal nachbessern, da scheint in der Tat zu viel rauszufliegen, hoffe, ich kann das zeitnah einchecken.

Ob die RG wegen des lösch-Befehls direkt verändert wird? (Müßte man testen, das wäre dann aber kaum ohne größeren Aufwand zu ändern...)

Das mit dem stateFormat dürfte geklärt sein, oder?

[ToKa]

Hallo Beta-User,

für alle denen noch die Umstellung bevorsteht, wäre es sicherlich gut, wenn der Alias erhalten bleibt. Ist ja kein exotisches Attribut.

RG hat ja nicht jeder im Einsatz - vielleicht reicht ja ein Hinweise in der Doku. Ja stateFormat ist geklärt.

Beste Grüße
Torsten

[Beta-User]

Das mit alias sollte "gegessen" sein (genauer: ab morgigem update).

Wg. RG muß ich mal sehen, bisher habe ich noch keine Idee, warum da was genau passiert... Vielleicht findet sich noch eine Erklärung, aber nach meinem bisherigen Eindruck sollten RG's eigentlich nicht betroffen sein, die nur mit dem Namen operieren, aber vielleicht übersehe ich da auch was.

Insgesamt scheint es ja trotzdem so zu sein, dass die Umstellung eine einmalige kleine Angelegenheit ist.

[Marlen]

Hallo,
ich hab gester ein Update gemacht, seit dem geht mein Heating_Control nicht mehr.
Ich bin jetzt auf diesen Beitrag gestoßen.
Scheinbar gibt es das Modul nicht mehr.
Allerdings ist in meinem Heatin_Controll auch kein Attribut converttoWDT.
Was mach ich falsch und vor allem wie bekommt man sowas schneller mit.

LG
  Marlen

[Beta-User]

Dass das Modul "deprecated" ist, ist seit ca. 8 Monaten angekündigt, seitdem gab es (beim Systemstart) auch entsprechende Verbose 3-Meldungen, die seit ca. 7-8 Wochen auch mit Verbose 1 ausgegeben werden.

Um das jetzt zu "reparieren", kannst du das Modul aus contrib laden, z.B. so:

Code Auswählen Erweitern

{ Svn_GetFile("contrib/98_Heating_Control.pm", "FHEM/98_Heating_Control.pm") }
Um die alten Devices wieder zu aktivieren, muß FHEM anschließend mit der alten fhem.cfg gestartet werden.

Danach kannst du das entweder so weiter laufen lassen (es wird nicht mehr aus "FHEM" entfernt werden, ich werde bei updates@WeekdayTimer aber auch nicht mehr danach schauen, ob es mit Heating_Contol zusammenarbeitet), oder den Code dazu nutzen, die Umstellung zu machen und dann hinterher Heating_Control wieder aus FHEM löschen.

Eventuell schaust du bei der Gelegenheit, ob es Sinn macht, das neue Feature "weekprofile" bei WeekdayTimer auszutesten .

[Marlen]

Was heißt mit der alten FHEM.cfg gestartet werden.....wodurch hat die sich verändert?

[Beta-User]

In die laufende Konfiguration wird nur geladen, was zulässig ist. Wenn du also ein Modul aus dem Modulverzeichnis (hier durch update) löschst, wird das betreffende define nicht ausgeführt.
Speicherst du dann die geladene Konfiguration, ist das betreffende Device nicht mehr in der fhem.cfg zu finden... Kurz: Du darst nicht speichern, dann sollte alles beim alten sein (u.a. wegen solcher Effekte hat man irgendwann die Möglichkeiten begrenzt, die Konfiguration automatisiert zu speichern...).

[Marlen]

Aber die Device sind doch da.
Funktionieren aber nicht.
Dachte gelesen zu haben, dass es einen converter gegeben hat.

LG Marlen

Gesendet von meinem Mi 9T mit Tapatalk

[Marlen]

Ich hab gerade mal den WeekdayTimer probiert, kann das sein, dass man da keine Befehle mit ausführen kann?

Ich hab halt immer recht viele Befehle mit drin:

Code Auswählen Erweitern

Zeitschaltuhr_Aquarium Mo-So|04:00|RGB0225.000.050.000 Mo-So|06:30|RGB0000.000.100.100 Mo-So|11:30|aus Mo-So|15:30|RGB0000.000.100.100 Mo-So|16:30|RGB0000.000.100.100 Mo-So|20:00|RGB0012.050.012.000 Mo-So|21:00|RGB0006.025.006.000 Mo-So|22:28|RGB0003.012.003.000 Mo-So|23:00|RGB0001.005.001.000.000 Mo-So|23:59|aus {
######## Farben als reading ######
fhem "setreading Farben_Zeitschaltuhr_Aquarium Farbe $EVENT";
######r## Beleuchtung
if ($EVENT eq "RGB0000.000.100.100") {# Haupt-Beleuchtung
fhem "setreading Farben_Zeitschaltuhr_Aquarium Beleuchtung Haupt";
#fhem "set MQTT_Aquarium $EVENT";
fhem "set Aquatium_Farbe_dmy $EVENT";
}elsif ($EVENT eq "aus") {
#fhem "set MQTT_Aquarium RGB0000.000.000.000";
fhem "set Aquatium_Farbe_dmy RGB0000.000.000.000";
fhem "setreading Farben_Zeitschaltuhr_Aquarium Beleuchtung Aus";
}elsif (Value("Alarmanlage_Status") eq "Unscharf") { # aus schalten, kein Bewohner da
#fhem "set MQTT_Aquarium $EVENT";
fhem "set Aquatium_Farbe_dmy $EVENT";
fhem "setreading Farben_Zeitschaltuhr_Aquarium Beleuchtung Ambiente";
}else{
fhem "setreading Farben_Zeitschaltuhr_Aquarium Beleuchtung Ambiente";
}
}

LG
  Marlen

[Beta-User]

Nochmal zur Erläuterung:
WeekdayTimer ist das Modul, das praktisch den kompletten Code enthält, Heating_Control war nur eine Art wrapper für WDT, es werden intern WeekdayTimer-Funktionen genutzt. Fast der einzige "eigene" Code in dem HC-Modul ist der "converter", nach dem du suchst. Dass der da steht und nicht woanders, macht  auch Sinn, denn es wird intern "list"-Code genutzt, um die Konfiguration der _geladenen_ HC-Devices nach WDT zu "übersetzen". Das setzt aber voraus, dass die betreffenden Devices überhaupt vorhanden sind, was nicht der Fall ist, wenn sie zwar noch in der fhem.cfg stehen, aber mangels Moduldatei das define nicht ausgeführt werden kann...

Kurz:
Halte dich bitte einfach an die Anleitung aus meinem letzten Post und schau nicht nur auf das, was (noch!) in deiner fhem.cfg steht.

WDT kann zwischenzeitlich noch ein paar Dinge mehr als HC, aber wie gesagt auch alles, was HC kann (nur die "führe jetzt aus"-Aufrufe haben sich etwas geändert) deswegen macht es mMn. Sinn, nur noch dieses Modul anzubieten.

Der WDT aus dem letzten Post wird vermutlich funktionieren, wenn er als HC-Device funktioniert hatte. Hat er aber vermutlich nicht in vollem Umfang, denn da ist  ein Problem drin, nämlich die überflüssige Angabe "Mo-So". Das "zerschießt" aus irgendeinem mir noch nicht bekannten Grund die Darstellung der Readings (funktionieren müßte er trotzdem, aber man sieht es eben nicht). Versuch's mal mit folgenden Zeitangaben in der ersten Zeile

Code Auswählen Erweitern

Zeitschaltuhr_Aquarium 04:00|RGB0225.000.050.000 06:30|RGB0000.000.100.100 11:30|aus 15:30|RGB0000.000.100.100 16:30|RGB0000.000.100.100 20:00|RGB0012.050.012.000 21:00|RGB0006.025.006.000 22:28|RGB0003.012.003.000 23:00|RGB0001.005.001.000.000 23:59|aus {
######## Farben als reading ######
[...]

[Marlen]

Ja, aber warum wurden nach meinem letzten Update die HC Device noch angezeigt, wenn doch durch den Update das HC Modul gelöscht wurde?
Ist das dann schon irgendwie einfach im WTD gelaufen....? Kann doch nicht sein!
Irgendwie wird bei einen WTD der nur On OFF macht, das WTD dann zwar auf on oder off gesetzt, aber der Code darunter ignoriert!

LG
  Marlen

[Beta-User]

Sorry Marlen, aber das ist ein ziemliches Ratespiel, das wir hier veranstalten...

Fakt ist: Wenn irgendein Modul nicht da ist, wird ein eintsprechendes define nicht ausgeführt, wenn FHEM neu gestartet wird, wie nach einem update üblich. Anders gesagt: aus einem Heating_Control-Device wird niemals automatisch ein WeekdayTimer!
Solange FHEM nicht neu gestartet wird, passiert auch mit bereits geladenem Code nichts...

Zu dem zweiten Thema ("Irgendwie wird bei einen WTD der nur On OFF macht...") möchte ich dich bitten, einen neuen Thread aufzumachen und dort freundlicherweise auch ein list von dem Ding einzustellen... (Diese mehrzeilige Schreibweise, die du in dem anderen verwendet hast, ist was neues, und nicht dafür gedacht, dass man den Code auch noch kommentiert. Wenn du das willst/brauchst, solltest du myUtils-Code aufrufen, da sollte das kein Problem sein...)