Doif - Durschnittswert wird nicht im PID20 Regler als sensor akzeptiert...

Begonnen von pure-current, 29 Januar 2019, 16:00:18

Vorheriges Thema - Nächstes Thema

pure-current

Hallo,

ich habe 2 Temperatursensoren (1-Wire), deren gemessene Durchschnittstemperatur mir als Eingangsgröße für einen PID20 Regler dienen soll.

Die Sensoren:

define 1wire GPIO4 BUSMASTER
define Raumtemp GPIO4 28-0113161a281e
attr Raumtemp stateFormat {round (ReadingsVal("Raumtemp","temperature","?"),1)}

define Raumtemp2 GPIO4 28-02131d9713aa
attr Raumtemp2 stateFormat {round (ReadingsVal("Raumtemp2","temperature","?"),1)}


Der PID20 Regler funktioniert jeweils mit EINEM gemessenen Wert, z.B.:
define Truma.Regler PID20 Raumtemp:temperature Truma.Servo

Im Forum habe ich für die Durchschnittsbildung gefunden:
define di_average DOIF ##
attr di_average state {(sprintf("%.1f",([Raumtemp:temperature]+[Raumtemp2:temperature])/2))}


Wenn ich im laufenden Betrieb jetzt beim PID20 das "Raumtemp:temperature" durch "di_average:state" ersetze funktioniert das Ganze tadellos.

Sobald ich aber einen Neustart mache, kommt die Fehlermeldung
Zitatconfigfile: Truma.Regler: Unknown sensor device di_average specified

Kann mir jemand helfen? Wie kriege ich den Durchschnittswert in den PID20? (so dass es auch nach einem reboot geht)

Gruß pure-current
Raspberry PI mit drei stackable CC (2x866MHz-HM&WMBUS, 1x433MHz-Somfy)
HM-LAN (Keymatic, Dimmer, Bewegungsmelder, Rolladen, Lichtschalter, KFM100)
div. Tasmota via MQTT

2. Raspberry Pi/FHEM im Wohnmobil (Heizungsregelung,GPS) Batterieüberwachung-toDo

Wzut

PID20 löschen und gleich wieder neu anlegen.
Theorie : die DoIf Idee kam dir später als der PID und daher steht jetzt der PID vor dem DoIf in der fhem.cfg.
Mit löschen und neu anlegen sorgst du dafür das er zukünftig nach dem DoIf steht.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

pure-current

@WZUT:

Deine Theorie ist richtig...
(Ich hab's aber mit Copy und Paste in der FHEM.cfg gemacht), der PID20 hatte zuviele attr's...

Aber es lag tatsächlich an der Reihenfolge...
Darauf wäre ich nie gekommen, ich dachte bisher immer, das wäre egal.
Aber logisch ist es natürlich!

Vielen Dank und Gruß,
pure-current
Raspberry PI mit drei stackable CC (2x866MHz-HM&WMBUS, 1x433MHz-Somfy)
HM-LAN (Keymatic, Dimmer, Bewegungsmelder, Rolladen, Lichtschalter, KFM100)
div. Tasmota via MQTT

2. Raspberry Pi/FHEM im Wohnmobil (Heizungsregelung,GPS) Batterieüberwachung-toDo

Wzut

Zitat von: pure-current am 29 Januar 2019, 16:44:17
(Ich hab's aber mit Copy und Paste in der FHEM.cfg gemacht)
Arrrr bist du still , das habe ich mit Absicht nicht geschrieben wegen der Jehova Rufer , nun wirst du am Kreuz enden .......
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Beta-User

Zitat von: Wzut am 29 Januar 2019, 17:04:58
Arrrr bist du still , das habe ich mit Absicht nicht geschrieben wegen der Jehova Rufer , nun wirst du am Kreuz enden .......
Politisch korrekte Handlungsanleitung für solcher Fälle: https://wiki.fhem.de/wiki/Import_von_Code_Snippets

Geht schneller, wie sich mit ssh anmelden und einen beliebigen Editor anwerfen...
=> Ab an's Kreuz mit euch beiden ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

pure-current

ich weiß das schon, dass das nicht gewünscht ist, die fhem.cfg direkt zu editieren, aber da die Fehlermeldung
Zitatconfigfile: Truma.Regler: Unknown sensor device di_average specified
kam, war das Device "Truma.Regler" ja gar nicht mehr zugänglich über die normale Oberfläche, es war ja quasi verschwunden.

In der fhem.cfg waren ja aber alle Daten noch da, man musste nur den Sensor verändern, dann tauchte das device wieder auf.

Also wie ich das sehe musste ich direkt über "edit files" gehen...  ;)
(wenns auch anders geht - klärt mich auf!)

Und da ich ja nur die Reihenfolge ändern wollte...

Also dann geh ich freiwillig ans Kreuz...
;)
Raspberry PI mit drei stackable CC (2x866MHz-HM&WMBUS, 1x433MHz-Somfy)
HM-LAN (Keymatic, Dimmer, Bewegungsmelder, Rolladen, Lichtschalter, KFM100)
div. Tasmota via MQTT

2. Raspberry Pi/FHEM im Wohnmobil (Heizungsregelung,GPS) Batterieüberwachung-toDo