Falsche pct Readings bei Rolladengeräten

Begonnen von Zeitisen, 08 März 2024, 10:17:03

Vorheriges Thema - Nächstes Thema

frank

am besten sieht man das "problem" beim log von zap.

wenn ich mir die bauanleitung vom HmIP-BROLL anschaue, macht sich eq3 die mühe, informationen auf 7 channels zu verteilen.
dabei zeigt channel 3 immer den aktuellen status von level und motor an.

HMCCU führt nun aber wieder alle level informationen aus allen channels zusammen in ein reading "pct/level".

also nur die level infos aus channel 3 betrachten und für asc verwenden.
dann gibt es auch maximal nur 2 positionen.

in channel 0 würde ich auch noch die zyklischen statusinfos abschalten, denke ich.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Zeitisen

Hallo,

ja wenn ich beim Status direkt 1.LEVEL verwende, könnte es gehen. Verifizieren muss ich noch, ob das ASC mit open und closed klar kommt.
Dann muss ich auch event-on-change-reading bei 1.LEVEL auf eine Minimum-Änderung einstellen.

Channel 0 wird bei mir im Device nicht verwendet.

Das mehrfache Auftreten von pct events mit unterschiedlichen Werten ist für mich ein Bug.

frank

Zitat von: Zeitisen am 10 März 2024, 21:27:02Dann muss ich auch event-on-change-reading bei 1.LEVEL auf eine Minimum-Änderung einstellen.
bei jeder änderung des motorstatus (up, down, stop) sendet das device auch eine aktuelle position. bei direkten fahrten also immer 2 positionen, kurz nach dem start und nach dem stop.
bei zusätzlichen referenzfahrten können es sogar 3 positionen sein, zb von 20 über 100 nach 80. die zwischenposition ist an der geänderten richtung zu erkennen.

du kannst auch dein asc modul ändern, so dass asc mit beliebig vielen zwischenpositionen klar kommt und immer korrekt manuelle fahrten erkennen kann. sogar automatische fahrten, die manuell gestoppt werden, sind dann manuelle fahrten.
https://forum.fhem.de/index.php?msg=1268272


Zitat von: Zeitisen am 10 März 2024, 21:27:02Das mehrfache Auftreten von pct events mit unterschiedlichen Werten ist für mich ein Bug.
die level infos aus den virtuellen aktor channels (4, 5, 6) sind ja vermutlich die sollwerte der jeweiligen channel.

sollwerte und istwerte in einem reading zu vereinen, ohne die unterschiede erkennen zu können, ist jedenfalls nicht sehr hilfreich. bei thermostaten gibt es ja extra 2 unterschiedliche readings.

bei 10_CUL_HM.pm gibt es das level reading, das auch soll- und istwerte enthält. allerdings sind hier die sollwerte durch einen prefix erkennbar (zb set_80).
und im ebenfalls vorhandenen reading pct gibt es nur die istwerte.



FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

zap

Das Update für HMCCU morgen reduziert die Anzahl der pct und level Reading Update
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

Zeitisen

Habe das Update gerade installiert und getestet.

Das schaut schon viel besser aus.

Die Änderungen zu ASC schau ich mir an.
Jetzt warte ich mal, was heute abend passiert.

Zeitisen

@frank
Deine vorgeschlagenen Änderungen zu ASC finde ich sinnvoll.
Nun sind die aber schon ein Jahr her und die Frage ist, ob und wie viel davon in das ASC-Modul bereits eingeflossen ist.
siehe

Zitat von: CoolTux am 01 September 2022, 15:42:52Ich muss gestehen daß ich gefallen an Deine Ideen gefunden habe. Sowohl der Weg über die tatsächliche Endposition sofern von ASC ausgelöst als auch das mit der IdleDetection finde ich sehr erfolgversprechend. Ich werde es mir in nächster Zeit einmal genauer anschauen.

Ich schrecke davor zurück, lokale Änderungen in einem Modul zu machen. Das zieht nämlich einen großen Pflegeaufwand nach sich.
Entweder muss ich dann das Modul aus dem automatischen Update herausnehmen, oder die Änderungen werden beim nächsten update überschrieben.

Wenn ich die Änderungen und Update übernehmen will, muss ich jeden Update gezielt anschauen.

Jetzt werde ich wohl oder übel doch noch vom SVN auschecken und schauen ob in den Log-Einträgen etwas zu finden ist.

Zeitisen

Leider ist hier gar nichts passiert:
source: trunk/fhem/FHEM/73_AutoShuttersControl.pm
Last change
 on this file was             26950, checked in by CoolTux, vor 14 Monaten

Zeitisen

Hier noch ein devStateIcon, das bei Bewegung ein anderes Icon in rot liefert.
Damit kann vor allem bei langsamen Rollos die Bewegung angezeigt werden.

attr 656E_5_Status_CH2 devStateIcon {if(ReadingsVal($name, "5.ACTIVITY_STATE", "UNSTABLE") eq "UP") \
    {".*:fts_shutter_up\@red"} \
 elsif(ReadingsVal($name, "5.ACTIVITY_STATE", "UNSTABLE") eq "DOWN")\
         {".*:fts_shutter_down\@red"}\
 else {"closed:door_shutter_100 [1-9]:door_shutter_90 1\\d:door_shutter_80 2\\d:door_shutter_70 3\\d:door_shutter_60 4\\d:door_shutter_50  5\\d:door_shutter_40 6\\d:door_shutter_30 7\\d.*:door_shutter_20   8\\d.*:door_shutter_10  open:door_shutter"}\
\
}