[erledigt mit fragezeichen] regensensor missing ack

[Beta-User]

@Sailor:

Ich habe das jetzt mal mit ins WIKI für den HMLAN unter "Bekannte Probleme" mit aufgenommen.

Das ist ein Thema, das nicht nur HMLAN betrifft, sondern alle Homematic-Interfaces bzw. teils auch die Kommunikation zwischen gepeerten Komponenten. Leider konnte ich das nicht mehr am richtigen Ort anmerken, weil jemand die Forenregeln nicht beachtet hat und den Thread geschlossen...

ja, aber warum?

Es ist m.E. nicht die Frage, warum man stateFormat bei CUL_HM-Geräten setzen will (da ist state mAn. in der Regel richtig aussagekräftig und das Setzen meistens überflüssig), sondern es geht darum, dass es als "gehärtetes" Attribut angesehen wird, und sich das Modul (ich hoffe: unbeabsichtigt) weigert, Wünsche des Users überhaupt entgegenzunehmen. Von daher ist

Alles andere kann man mit userreadings und stateformat sowieso selbst erledigen.

nicht passend, weil stateFormat "zu" ist...

ich merke auf jeden fall folgendes: leg ich ein userreading an, daß den state ausliest, dann hab ich in den doifs damit die selben probleme wie mit dem state selber - irgendwie auch logisch, denk ich.

Ja, das wird genauso oft (mit) getriggert wie state. Du müßtest auf was anders in der Auswertung gehen bzw. dem Trigger für das userReadings, nehme ich mal an.

@Martin:
Bei mir dauert das deutlich länger mit dem initial cleanup:

Code Auswählen Erweitern


2021.09.18 13:13:50 1: CUL_HM start inital cleanup
2021.09.18 13:13:50 1: PERL WARNING: Use of uninitialized value in substitution (s///) at ./FHEM/10_CUL_HM.pm line 10715.
2021.09.18 13:13:50 3: Device Balkontuer added to ActionDetector with 028:00 time
2021.09.18 13:13:50 3: Device Bewegungsmelder_1 added to ActionDetector with 000:10 time
[...mehr ActionDetector]
2021.09.18 13:13:52 3: Device Thermostat_Wohnzimmer_SSW added to ActionDetector with 000:10 time
2021.09.18 13:13:55 1: CUL_HM finished initial cleanup
(10715 ist nicht die Zeile der offiziellen Version).
Dabei ist der Punkt aber der: bei HMinfo steht verbose auf 2, tatsächlich werden ganz viele getConfig-Befehle abgesetzt, die mAn. auch "doppelt und dreifach" sind. Evtl. besteht auch eine Verbindung zwischen dem und den "missing ack"-Geschichten von @Sailor und @the ratman dahingehend, dass die Sendequeue unnötig voll ist?

Da wir grade dabei sind: Mein CUL (steht unter VCCU-Kontrolle) taucht neuerdings auch mit "komischen" Meldungen im Log auf:

Code Auswählen Erweitern

2021.09.18 13:55:52 3: CUL_HM set Virtueller_FK_SZ postEvent open
2021.09.18 13:55:52 3: CUL_0: Unknown code ? (remove:2E7A30 is unknown) Use one of A B b C e F G h i K k L l M m N R T t U u V W X x Y Z, help me!
Der virtuelle Fensterkontakt ist - wie der Name schon sagt - ein Kanal von einem virtuellen CUL_HM-Gerät, der wiederum gepeert ist mit dem fraglichen Thermostat (HM-CC-RT-DN), genauer: dem WindowRec-Kanal.

[the ratman]

irgendwas haut mit dem regensensor nicht wirklich hin ...

die regenmeldung kommt nicht immer, wenn sie kommen sollte.
seit 2 stunden jetzt nieselts hier vor sich hin. die regenmeldung kam erst, nachdem ich ein "set getconfig" gemacht hab.
letzteres ist auch affenschnell abgearbeitet worden. keine warnigs oder fehler im log ...

schaut hier einfach so aus, als ob der kanal einfach selbsständig nix machen würde. aber auch erst nach einer gewissen zeit. wenn ichs ned besser wüßte, würd ich sagen, der geht schlafen und wacht nimma auf. als ich gestern nach dem zusammenbau noch mit nem glas wasser getestet hab, war der sofort mit regen da.

dies aber bitte mit vorsicht zu genießen. ich hab das ding schon wieder am dach angeschraubt, kanns also nur schwer spontan testen.

[frank]

sniffe die raw messages vom sensor, dann siehst du, wann er was zu melden hat.
sind die event-...-attribute richtig gesetzt?

[the ratman]

is bei mir alles auf standard
sniffen? womit und wie?

und das problem generell: wie krieg ich ohne regensensor mit, daß es regnet? nur weil der nix sendet, heißts ja nicht unbedingt, daß er nicht funktioniert.
wird mir wohl nix anderes übrig bleiben ... abbauen und unter "laborbedienungen" regnen lassen *g*.

[frank]

sniffen: kennst du schon => "attr name_io logIDs name_sensor"
dann würde ich im eventmonitor alle events vom sensor "filtern" und zusätzlich die option fhem.log einschalten.
dann hat man alles zusammen im blick.

laborbedingungen sind natürlich optimal 
(oder mit wasserpistole/gartenschlauch beschiessen?)

[the ratman]

leider nix mit gartenschlauch ... zu weit oben.
mal schauen, wann ich mich motivieren kann.

heute früh hat er wenigstens richtig "dry" gemeldet - das gibt mal hoffnung auf fehleinschätzungen meinerseits *g*
eh klar, daß es die nächsten tage nicht regnen soll hier. kann also dauern, bis ich mir sicher sein kann.

[the ratman]

war wohl doch meine ungeduld.
nachbar hat mir seine pumpe geborgt - die kommt bis zum sensor. 3 mal probiert, 3 mal gefunzt.
ein bissi lahm ist der beim dry-melden, obwohl ich ihn von 5 min auf 30 sek. gedrückt hab - aber damit kann ich leben.

derzeit also mal entwarnung, bis mir neues mimimi für euch einfällt.
wie immer: thx für euer gehirnschmalz!

[the ratman]

sodale ...

ich bin mir jetzt relativ sicher, dass der sensor physikalisch funktioniert.

bliebe nur noch mein problem mit dem state.
ich will nicht drüber streiten, ob da doif, homematic, die sonnenfleckenaktivität, oder sonst was schuld ist ... generell gibt's hier probleme, die mit einem eigenen reading ausgenommen werden könnten.
hier funzt alles, was mit doif und hm zu tun hat. sobald ich aber "addstateevent" mit rein nehmen muss, geht's nur mehr meistens.
manches mal kriegt das doif dann scheinbar nicht mit, dass sich was geändert hat. ist halt grad bei der regen erkennung, die meine rollos usw. fahren soll, extrem nervig.

die bitte also: eigene readings für den regensensor (wenigstens den regen-kanal). und wenn's andere sensoren gibt, die sich ähnlich verhalten, werden die entsprechenden leute sicher auch keine beschwerden haben, wenn's neue readings gibt.

[frank]

sobald ich aber "addstateevent" mit rein nehmen muss, geht's nur mehr meistens.

hört sich an wie ein wackelkontakt, den es aber sicherlich nicht gibt. 
vermutlich passt dort deine "filterung" nicht richtig.

ein separates rain reading wäre schon hilfreich.
aber auch ohne muss und wird es eine immer funktionierende lösung geben.

[the ratman]

sagen wir's mal so: wenn/sobald es mal ein eigenes reading gibt, sind wir alle schlauer *g*
das ist grad auch der dümmste sensor zum rumprobieren hier.

[the ratman]

ich hab jetzt übrigens ein schönes bspl. für das nicht richtige funzen von doif's im zusammenhang mit meinem regensensor.

ich hab ein doif, dass schreibt je nach zustand des hauses (z.b. tag/nacht) für meinen regenplot nicht nur rain/dry, sondern auch noch verschiedene zahlen. dazu wird die heizung dann auch gleich passend geschaltet.
so kann ich dann im plot unter anderem abbilden, wenn am tag die heizung des sensor rennt, in der nacht aber nicht.

bspl. (AUSZUG):

Code Auswählen Erweitern

(
   [HM_70FEFD_Rain:"^state: rain$"]
   and [$SELF:zustand] eq "an"
)

( set HM_70FEFD_Heating on-for-timer 300 )
( setreading $SELF regen_echt 255 )

DOELSEIF ## 02

(
   [HM_70FEFD_Rain:"^state: rain$"]
   and [$SELF:zustand] eq "aus"
)

( set HM_70FEFD_Heating off)
( setreading $SELF regen_echt 130 )"addStateEvent" ist dabei natürlich ein.

ändert sich jetzt beim aufstehen der zustand von [$SELF:zustand] auf "an", passiert trotz passender werte im sensor mal gar nix ... das war früher (bevor dieses dämliche "ich-schreibe-alles-in-state-rein"-desaster begonnen hat) 100% funktionabel.

[frank]

ich denke, du verknüpfst (and) einen zustand von $self mit einem event (rain/dry) vom sensor.

wenn sich ein zustand ändert, kann nie gleichzeitig ein anderes event auftreten. vermutlich triggert das doif erst, wenn das rain event kommt und gleichzeitig der zustand von $self passt.

solange du den unterschied von zustand und event nicht verstehst oder verstehen willst, werden deine doifs nur zufällig so funktionieren, wie du es erwartest.

dir fehlt also der fall, dass sich der zustand von $self auf an ändert während gleichzeitig der zustand des sensors auf rain steht.
hier kommt jetzt wahrscheinlich erschwerend hinzu, dass im state vom sensor channel nicht nur rain/dry auftauchen kann.

ich würde als erstes ein "funktionierendes" userreading im sensor anlegen, dass rain/dry aus dem state filtert.
deins kopiert ja nur den state.

vermutlich wärst du im doif bereich mit diesem problem besser dran.

[frank]

da fällt mir ein, dass du auch wieder dein altes (ganz schlechtes) doif nutzen könntest, wenn du ein neues attribut nutzt.
https://forum.fhem.de/index.php/topic,120240.msg1169707.html#msg1169707

weitere neue readings bringen aber wieder die gleichen probleme.

[the ratman]

wenn sich ein zustand ändert, kann nie gleichzeitig ein anderes event auftreten. vermutlich triggert das doif erst, wenn das rain event kommt und gleichzeitig der zustand von $self passt.

der $self zustand ändert sich normal nur 1 mal am tag.
und wie gesagt: genau so hats immer schon gefunzt - nur seitdem state so gesprächig wurde ists auf einmal ein problem.

ich würde als erstes ein "funktionierendes" userreading im sensor anlegen, dass rain/dry aus dem state filtert.
deins kopiert ja nur den state.

wie würde das aussehen? kann zwar generelles zeug anlegen (von mir selber abschreiben *g*), aber filtern ist nicht so meines - kannst mir das hier rein schreiben bittescheen?

[frank]

wenn das kein zufall ist
https://forum.fhem.de/index.php/topic,123154.msg1176834.html#msg1176834

das userreading muss ich erst testen.