Modul weekprofile + FHEMWEB widget

Begonnen von Risiko, 23 Dezember 2015, 20:16:54

Vorheriges Thema - Nächstes Thema

Risiko

#675
Zitat von: beaune am 17 September 2021, 12:37:50
Hallo beaune,

mir geht es nicht um den Aufwand und die größer der Änderung in weekprofile. Mir geht es um einen einheitlichen Ansatz, welcher hier meiner Meinung nach verletzt wird, welcher für alle mir bekannten Heizsysteme aber passt. Weekprofile wurde designed um Wochenprofile (Zeit + Temperatur) zu verwalten und diese einfach um\einstellen zu können. Ein Wochenprofil legt fest, welche Temperatur an welchem Tag zu welcher Uhrzeit vorliegen soll. Zum ein- bzw verstellen eines Profils schickt weekprofile das Profil an ein Modul, welches die Einstellung dann vornimmt (hier ist ja nicht gesagt, dass die Hardware z.B. Thermostat das Profil direkt annimmt\speichert). 

Meiner Meinung nach fehlt eben hier an ein Modul, was das "Sonderverhalten" von ebus gegenüber einer Homatic, MAX, "normalen Thermostaten" ausgleicht.
Ich habe verstanden, dass dein System keine Verwaltung Zeit + Temperatur kann. ABER man kann Sollwerte einstellen. Bei Homatic oder MAX stellt das Gerät\Thermostat selbst den Sollwert entsprechend Zeitintervall ein. Das müsste hier meiner Meinung nach ein FHEM-Modul machen.  Also eine Übersetzung von einem Wochenprofil in die ebus Logik.
Bei all mir bekannten Systemen kann man die Solltemperatur unabhängig vom Profil\Zeitplan einstellen. Das hat aber überhaupt nichts mit weekprofile zu tun.

Wenn es so nicht passt, dann ist weekprofile nicht das richtige Modul (auch wenn ggf. vieles verwendet werden könnte).
Wenn es eben nur um Zeitpläne geht, dann wäre meiner Meinung nach ein anderes Modul notwendig.

Risiko




Beta-User

Zitat von: Risiko am 18 September 2021, 20:39:23
Habs gefixt.
Danke!

Jetzt hoffen wir mal, dass die Änderung nicht "komische" Nebenwirkungen hat - das Problem ist, dass weekprofile damit möglicherweise die Funktionen aus 99_Utils überschrieben hatte und _andere_ Module/myUtils-Funktionen, die min/max haben wollen, plötzlich anders funktionieren, falls weekprofile das einzige Modul war, das an der Stelle so gestrickt war.

Zitat
data::Dumper wird doch nur im Fehlerfall verwendet, um die Daten auszugeben und nicht zur JSON-Evaluierung selbst.
Auch hier besteht m.E. nach wie vor das Problem, dass Data::Dumper durch dieses use in main verfügbar wird. also wenn überhaupt, sollte man vermutlich das use nur im Fehlerfall (in der konkreten Teilfunktion) absetzen. Muss aber zugeben, dass ich das auch nicht in der letzten Verästelung verstanden habe, vielleicht schaust du mal in https://forum.fhem.de/index.php/topic,109755.0.html rein. Da ist btw. auch noch "Storable" als Kritikpunkt zu finden.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Risiko

Zitat von: Beta-User am 06 September 2021, 10:07:41
@Risiko:
- zum anderen ist das userAttr "weekprofile" ja (aus Sicht der commandref) eigentlich eines, das zu weekprofile gehört. Dazu müsste man aber den betreffenden "fremden Modul-Instanzen" mitteilen, dass die Hilfe aus weekprofile kommt. Da es nur einzelne Instanzen betrifft (und nicht alle), müsste für diese Fälle dann addToDevAttrList aufgerufen werden, siehe Link unten (erster commit, die Schleife war da aber schon da).
Habe das heute mal eingebaut. Das userattr wird auch angelegt, doch die Hilfe wird bei der Selektion von weekprfofile im fremden Device nicht angezeigt. Muss man da noch was beachten z.B. abweichende ID-Syntax? Finde zu dem Thema leider auch (mal wieder) keine Dokumentation.

Beta-User

Zitat von: Risiko am 19 September 2021, 20:50:34
Habe das heute mal eingebaut. Das userattr wird auch angelegt, doch die Hilfe wird bei der Selektion von weekprfofile im fremden Device nicht angezeigt. Muss man da noch was beachten z.B. abweichende ID-Syntax? Finde zu dem Thema leider auch (mal wieder) keine Dokumentation.
Na ja, die "Doku" sind nachfolgender Beitrag von Rudi und entsprechende Beispiele, auf die ja verlinkt war:
Zitat von: rudolfkoenig am 09 Juli 2021, 19:38:02
Das funktioniert mit data-pattern="o.*Cmd" (gerade getestet).
Wichtig: das ID der ersten <a> in der Hilfe dient als Modulbezeichner, d.h. die Hilfe sollte mit <a id="RandomTimer"></a> anfangen.
Um das zu wissen, muss FHEM wissen, wer dieses Attribut spendiert hat.

Ich habe jetzt addToDevAttrList und addToAttrList mit einem optionalen $module Parameter erweitert, damit kann man die Quelle spezifizieren.

Damit erscheinen in der Liste die FHEMWEB Attribute im FHEMWEB-Abschnitt (und nicht mehr unter "global userattr") und die Modul eigenen Attribute unter dem Abschnitt mit dem Modulnamen (nicht mehr "Module").
Letzteres kann man als Nachteil empfinden, weil damit die Modulattribute je nach Modulnamen ganz nach unten rutschen koennen.

Benötigt wird also ein entsprechender Abschnitt in der commandref, z.B.:
Zitat
<a id="weekprofile-attr-weekprofile"></a>
Helps weekprofile to identify it's client devices at the time a <i>restore_topi</i> command is issued.

Und in den (CUL_HM, MAX, ....-) Client-Instanzen muss das userattr eben über addToDevAttrList() nicht "allgemein" vohanden sein, sondern dort muss ergänzend das "weekprofile" (als Modulkenner) gesetzt sein, wie hier für AutoShuttersControl:
             
- addToDevAttrList( $shuttersDev, $attrib )
+ addToDevAttrList( $shuttersDev, $attrib, 'AutoShuttersControl' )

Ergo müßte in der Schleife für alle Clients dann eben sowas stehen:
addToDevAttrList( $clientDev, 'weekprofile', 'weekprofile' )

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Risiko

Danke. So ausführlich wäre es garnicht notwendig gewesen  ;). Mein Fehler war der optionale Parameter in addToDevAttrList

Beta-User

Gerne. Hatte nur gesehen, dass der Link auf den commit irgendwie kaputt ist, und dann ist es in der Tat etwas schwierig nachzuvollziehen, an was es hängt bzw. wie das konkret aussehen muss...

Danke für's Aufgreifen der Anregung!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

stolus

@Risiko
Ich nutze das Modul "weekprofile" schon länger, vielen Dank für Deine Arbeit!

Im Moment habe ich gerade den Überblick verloren welche Arten von Devices unterstützt werden.
Ich bin auf das Modul "HMCCU" (Raspberymatic) umgestiegen und nutze die Version 5.0 von HMCCU.

Die meisten Devices in FHEM (z.B. HM-CC-RT-DN) werden jetzt in Version 5.0 als TYPE=HMCCUCHN angelegt, beim Übertragen des profils (send to device) kommt die Fehlermeldung "Error device type not supported"

Ich habe mehrere Thermostate zu Heizgruppen in der CCU (Raspberymatic) zusammengefügt, daraus wird in FHEM ein Device mit dem TYPE=HMCCUDEV, allerdings ein VirtualDevices ccutype=HM-CC-VG-1.
Beim Übertragen des profils (send to device) kommt die Fehlermeldung: "KEL.Wohnen.Heizgruppe Invalid parameter specified. Valid parameters are HASH(0x55fe5e9b1328)"

Hier komme ich leider alleine nicht weiter und benötige eine Rat.

FHEM im Proxmox LXC
Raspberrymatic mit HB-RF-USB-2 für Homematic
ESPEasy/Tasmota/Shelly
Bayernlüfter, Plenticore Solar mit KSME EM410, EVCC mit E-Auto
Vailliant Arotherm Plus Wp mit ebus

Risiko

Hallo stolus,

ich habe von dieser Hardware keine Ahnung, bekomme das auch nicht mit und kann daher immer nur hinterher programmieren, wenn es auf der Seite (von Homatic, Raspberymatic, etc.) was Neues gibt. Dazu benötige ich natürlich die Informationen von euch Usern (list vom Device, Readings, Befehl zum setzen des Profils).
Leider hält sich der Homatic-Entwickler aus meiner Sicht nicht an irgend eine Konvention bzw. Logik (jedenfalls mir nicht ersichtlich).

Also wenn du mir die notwendigen Informationen zur Verfügung stellen kannst, dann kann ich mal schauen was sich machen lässt.

Risiko

kadettilac89

@Risiko

HMCCU ist das Modul welches eine originale CCU2 / CCU3 (und Derivate wie Raspberrymatic) anspricht. Das ist eine eigene Homematic Zentrale die mit den Thermostaten kommuniziert. Es ist ein alternatives Setup mit eigenen Readings und Verhalten. Da wirst du kaum etwas aus der vorhandenen Homematic Implementierung übernehmen können. Bei der aktuellen Implementierung ist Fhem die Zentrale und Thermostate sind in Fhem angebunden. Bei einer CCU sind die Thermostate an die CCU angelernt und angebunden. Fhem kommuniziert dann mit der CCU

@stolus, welche Hardware nutzt du, hast du HOmematic IP im Einsatz?

stolus

@Risiko
ich habe drei Lists der Devices HM-CC-RT-DN (Homematic Heizkörperthermostat), HM-TC-IT-WM-W-EU (Homematic Wandthermostat) und von dem virtuellen Device HM-CC-VG angehängt.
Die ersten beiden sind jetzt Device vom TYPE=HMCCUCHN, ich vermute das dort der Unterschied liegt.
FHEM im Proxmox LXC
Raspberrymatic mit HB-RF-USB-2 für Homematic
ESPEasy/Tasmota/Shelly
Bayernlüfter, Plenticore Solar mit KSME EM410, EVCC mit E-Auto
Vailliant Arotherm Plus Wp mit ebus

Risiko

Hallo stolus,

HMCCUCHN kannte weekprofile noch nicht. Anbei eine Testversion, wo es hoffentlich geht.

Das HM-CC-VG-1 vom Typ HMCCUDEV sollte eigentlich funktionieren. Dann bräuchte ich mal ein Log von weekprofile mit verbose 4 beim Senden\Übertragen des Profils
Da es ein virtuelles Device ist, ist vermutlich der Befehlssyntax anders!? Wie ist denn der genaue Befehl zum Setzen eines Profils bei diesem virtuellen Device?

Kann man ccuif zur Erkennung eines virtuellen Devices nehmen?

Risiko

DS_Starter

Hallo beaune, @all

dank deinen Hinweisen und natürlich der Vorleistung weiterer User im Umfeld eBus (Adapter) habe ich jetzt meine Vaillant in FHEM + Dashboard über MQTT2 eingebunden und kann schon ganz hervorragend auswerten und steuern.

Bekanntlich kommt der Appetit beim Essen und ich möchte das Thema bei mir weitertreiben.
Jetzt kommt weekprofile ins Spiel was ich schon lange hervorragend zur Steuerung meiner Homematic classic Steuerelemente nutze.
Für die Ansteuerung von MQTT2 wird zusätzlicher Code benötigt. Die jeweiligen MQTT Topics zum publishen sind mir inzwischen geläufig. Ich frage mich momentan nur wo ich weekprofile am besten mitteile welche Topics zum MQTT_DEVICE gesendet werden sollen.

Ich hatte vermutet es gibt so eine Art Attribut für setList, also etwa wenn eine Temp von 50°C eingestellt werden soll:


50 => 1_RadiatorenHK_Tagtemperatur_Soll 50


Das würde dann ein


set <MQTT2_DEVICE> 1_RadiatorenHK_Tagtemperatur_Soll 50


senden. Es gibt ja das Userattr weekprofile um die Verknüpfung des Zieldevices mit weekprofile vorzunehmen.
Im <MQTT2_DEVICE> würde dann ein setList die Übersetzung in das MQTT Topic vornehmen, z.B.:

1_RadiatorenHK_Tagtemperatur_Soll ebusd/700/z1DayTemp/set $EVTPART1

Habe ich etwas übersehen ? Wie implementiert du/ihr so etwas ?

Grüße,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Beta-User

@DS_Starter: Du solltest dazu einen separaten Thread starten (oder dich in einen der bestehenden einklinken).

Kurzfassung:
- weekprofile (direkt) mit MQTT2_DEVICE ist dazu gedacht, das komplette Profil an das Zieldevice zu übertragen (Zusatzcode zur Umwandlung in das "passende" Profilformat ist erforderlich). Das Profil läuft dann aber unmittelbar auf dem Zieldevice.
- um "nur" zum richtigen Zeitpunkt eine neue Temperatur an das Gerät zu senden, bist du bei WeekdayTimer besser aufgehoben. Das kann auch über weekprofile "ad hoc" umgestellt werden, die Überwachung der Schaltzeiten übernimmt dann aber FHEM.

Was du hier zu wollen scheinst, ist imo weekprofile => WeekdayTimer => MQTT2_DEVICE => Zielgerät

PS: Willkommen an Bord!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

DS_Starter

Zitat@DS_Starter: Du solltest dazu einen separaten Thread starten (oder dich in einen der bestehenden einklinken).
Ja passt, ich dachte das wäre der passende. Aber dann schaue ich mal ob es einen besseren gibt.

Zitat
- weekprofile (direkt) mit MQTT2_DEVICE ist dazu gedacht, das komplette Profil an das Zieldevice zu übertragen (Zusatzcode zur Umwandlung in das "passende" Profilformat ist erforderlich). Das Profil läuft dann aber unmittelbar auf dem Zieldevice.

An so etwas dachte ich. In der Heizung wird für jeden Tag ein Verlaufsprofil gespeichert, z.B.:

ebusd_700_hwcTimer.Friday
{
     "0": {"name": "from", "value": "05:30"},
     "1": {"name": "to", "value": "22:00"},
     "2": {"name": "from", "value": "-:-"},
     "3": {"name": "to", "value": "-:-"},
     "4": {"name": "from", "value": "-:-"},
     "5": {"name": "to", "value": "-:-"}
}


Jetzt muß man "nur" noch das MQTT Topic "ebusd/700/hwcTimer/set ..." an das FHEM MQTT2 Device senden um den Plan in der Heizung zu setzen. Die Stelle suche ich um weekprofile dies mitzuteilen. Eigener Code ist kein Problem ... nur wo das weekprofile mitteilen ?
Sorry wenn das hier vllt. wieder OT ist ... evtl. mache ich doch einen neuen Thread auf ;)

LG
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Beta-User

Dazu muss "Friday" gesetzt werden können. Diskussion/Anleitung dazu gibt es bereits unter https://forum.fhem.de/index.php/topic,122120.0.html ;)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files