Moin,
im Homematic Bereich wird gerade ein komisches Phänomen diskutiert. Der ActionDetector (device vom TYPE=CUL_HM) wird in FHEMWEB nicht mehr angezeigt. Wenn man dem device einen room per Attribut zuweist, wird der Raum links in der Navigation zwar angezeigt, er ist aber leer. Das device ist aber vorhanden und funktioniert einwandfrei.
Kann mir jemand einen Tipp geben, wie man der Ursache auf die Spur kommen kann?
Internals:
DEF 000000
FUUID 5c79965f-f33f-6a1b-d744-c28b77d8fb71135e
NAME ActionDetector
NOTIFYDEV global
NR 72
STATE alive:5 dead:0 unkn:0 off:0
TYPE CUL_HM
chanNo 01
READINGS:
2019-03-01 21:30:26 state alive:5 dead:0 unkn:0 off:0
2019-03-01 21:30:26 status_bd_RT alive
2019-03-01 21:30:26 status_bd_TC alive
2019-03-01 21:30:26 status_wz_Balkon alive
2019-03-01 21:30:26 status_wz_RT alive
2019-03-01 21:30:26 status_wz_TC alive
helper:
HM_CMDNR 183
actCycle 600
mId
peerFriend -
peerOpt -
peers 3A7AE0,3B015E,3FB012,50C708,645DFD
regLst
3A7AE0:
start 2019-03-01 21:30:26
3B015E:
start 2019-03-01 21:30:26
3FB012:
start 2019-03-01 21:30:25
50C708:
start 2019-03-01 21:30:23
645DFD:
start 2019-03-01 21:30:24
io:
newChn +000000,00,00,00
prefIO
rxt 0
vccu
p:
000000
00
00
00
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
Attributes:
event-on-change-reading .*
model ActionDetector
subType
Ein gesetztes column Attribut in FHEMWEB mit einer im entsprechenden Raum nicht vorhandenen Gruppe kann z.B. das Problem auslösen.
Klingt in dem Fall aber unwahrscheinlich.
Zitat von: marvin78 am 01 März 2019, 21:35:10
Klingt in dem Fall aber unwahrscheinlich.
Das Attribut ist nicht vorhanden. Und ob der ActionDetector einen room und / oder eine group zugewiesen hat, ändert nichts an seiner "Tarnung"
Beim Aufruf des room in dem sich ausschließlich das vermisste device befindet, passiert im Logfile folgendes
019.03.01 21:46:23 4: web_192.168.0.178_52702 GET /fhem?room=Unsorted&fw_id=98; BUFLEN:0
2019.03.01 21:46:23 4: Ignoring unknown_261B9E
2019.03.01 21:46:23 4: Ignoring unknown_B48898
2019.03.01 21:46:23 4: Ignoring unknown_261866
2019.03.01 21:46:23 4: Ignoring unknown_20DACD
2019.03.01 21:46:23 4: Ignoring unknown_22B309
2019.03.01 21:46:23 4: Ignoring unknown_2286BC
2019.03.01 21:46:23 4: Ignoring unknown_B4889A
2019.03.01 21:46:23 4: Ignoring unknown_228734
2019.03.01 21:46:23 4: Ignoring unknown_21C0B8
2019.03.01 21:46:23 4: Ignoring unknown_21CCB3
2019.03.01 21:46:23 4: Ignoring unknown_127000
2019.03.01 21:46:23 4: Ignoring unknown_23C776
2019.03.01 21:46:23 4: Ignoring unknown_B48899
2019.03.01 21:46:23 4: web: /fhem?room=Unsorted&fw_id=98 / RL:2244 / text/html; charset=UTF-8 / Content-Encoding: gzip
/ Cache-Control: no-cache, no-store, must-revalidate
2019.03.01 21:46:23 4: web_192.168.0.178_52702 GET /fhem?XHR=1&inform=type=status;filter=room=Unsorted;since=1551473182;fmt=JSON&fw_id=98×tamp=1551473179636; BUFLEN:0
2019.03.01 21:46:24 4: Connection closed for web_192.168.0.178_52702: EOF
2019.03.01 21:46:24 4: web_192.168.0.178_52703 GET /fhem?room=00%20test; BUFLEN:0
2019.03.01 21:46:24 4: web: /fhem?room=00%20test / RL:2093 / text/html; charset=UTF-8 / Content-Encoding: gzip
/ Cache-Control: no-cache, no-store, must-revalidate
2019.03.01 21:46:25 4: web_192.168.0.178_52703 GET /fhem?XHR=1&inform=type=status;filter=room=00%20test;since=1551473183;fmt=JSON&fw_id=101×tamp=1551473181151; BUFLEN:0
2019.03.01 21:46:30 4: Connection closed for web_192.168.0.178_52703: EOF
2019.03.01 21:46:30 4: web_192.168.0.178_52704 POST /fhem&fw_id=101&room=00+test&fwcsrf=csrf_346763671122355&cmd=attr+global+verbose+3; BUFLEN:0
2019.03.01 21:46:30 5: Cmd: >attr global verbose 3<
In der JavaScript Console sind keine Fehler erkennbar.
Im HTML Quelltext der Seite steht in dem betreffenden Abschnitt
<div id="hdr">
<table border="0" class="header"><tr><td style="padding:0">
<form method="post" action="/fhem">
<input type="hidden" name="fw_id" value="116"/>
<input type="hidden" name="room" value="00 test"/>
<input type="hidden" name="fwcsrf" value="csrf_346763671122355"/>
<input type='text' name='cmd' class='maininput' size='80' value='' autocorrect='off' autocapitalize='off'/>
</form>
</td></tr></table>
</div>
<form method="post" action="/fhem" autocomplete="off">
<div id='content' room='00 test'>
<table class="roomoverview">
</table>
</div>
</form>
</body></html>
wenn das device temporary ist wird der raum ignoriert.
Dann taucht das device aber immer noch unter "unsorted" auf.
Der ActionDetector ist kein temporary device.
@Andre: auch der Zugriff von readingsGroup auf das device funktioniert nicht mehr.
https://forum.fhem.de/index.php/topic,98028.0.html
Ok, ich bin ein Stück weiter: Das device wird nicht angezeigt, weil in $FW_types{'ActionDetector'} kein Wert steht.
Jetzt muss ich nur noch rausfinden, wo/wie dieser hash gefüllt und und warum für dieses device nix drinsteht.
ok, ich habs gefunden. Das leere Attribut "subType" im ActionDetector ist schuld.
ZitatDas leere Attribut "subType" im ActionDetector ist schuld.
FW_types (was mit subType, TYPE oder model gefuellt wird), wird fuer die Anzeige der Gruppenueberschrift verwendet.
Bin unsicher, was bei einem leeres subType passieren soll.
dann TYPE als fallback ?
Mich interessiert eher, ob ein leeres subType sinnvoll ist.
Insb. da sowas nur vom Modul direkt gesetzt werden kann, ein Benutzer ist nicht in der Lage ein Attributwert auf nichts zu setzen.
das war aber nicht deine frage :)
einerseits ist das die alte frage ob leere readings und attribute erlaubt sein sollen weil sie etwas andere bedeuten wie ein nicht vorhandenes reading/attribut.
ja. können sie. hängt aber vom anwendungsfall ab.
ob es hier sinnvoll ist? ich denke nicht und vermute eher ein unbeabsichtigtes problem. aber das kann nur martin sagen.
Das kann nicht nur Martin beantworten, da ich mich gestern ungefähr zwei Stunden mit dem Thema befasst habe :)
Zitat von: rudolfkoenig am 02 März 2019, 12:26:19
FW_types (was mit subType, TYPE oder model gefuellt wird), wird fuer die Anzeige der Gruppenueberschrift verwendet.
Bin unsicher, was bei einem leeres subType passieren soll.
Es war nicht beabsichtigt, sondern resultierte aus einem radikalen Umbau im Modul CUL_HM. Ab dem morgigen Update ist das Attribut subType bei ActionDetector auch mit einem sinnvollen Wert gefüllt.
Bei einem nicht vorhandenen $FW_types{$dev} wird die Verarbeitung in FW_showRoom() mit dem nächsten Device fortgesetzt), noch bevor es zu einer Prüfung der Gruppenzugehörigkeit kommt.
1918: next if(!$FW_types{$dev}); # FHEMWEB connection, missed due to caching
Zitat von: justme1968 am 02 März 2019, 12:56:05
einerseits ist das die alte frage ob leere readings und attribute erlaubt sein sollen weil sie etwas andere bedeuten wie ein nicht vorhandenes reading/attribut.
Genau das war hier mal wieder die "Falle". Das Attribut war vorhanden, deshalb hat der default-Wert (TYPE) nicht gezogen, obwohl es keinen Wert für das Attribut gab.
Zum Thema "Attribute sind alleine aufgrund ihrer Existenz schon auszuwerten, auch wenn sie keinen Wert besitzen" habe ich noch eine Anmerkung.
GetDefAndAttr() in fhem.pl kommt mit Attributen, die zwar vorhanden sind, aber keinen Wert besitzen, definitiv nicht klar und schreibt pro Attribut dieser Art mindestens drei Warnungen ins Logfile.
Interessanterweise wurde gerade aktuell von Rudi folgende Antwort zu perl Warnungen bezüglich fehlender Werte gegeben
Zitat
Da das nicht in Ordnung ist, bin der Meinung, dass eine Warnung genau die richtige Reaktion des Systems ist.
=> Wir sollten die Ursache fixen, und fuer den Hinweis dankbar sein.
wobei es im beschriebenen Fall zugegebenermaßen um Internals ohne einen Wert ging. Warum das Verhalten bei readings und attributes ok sein soll, bei internals aber nicht, kann ich nicht nachvollziehen.
Die Begründung "das ist schon immer so" mag ich dabei nicht gelten lassen.