Warum ignoriert CUL_HM das attr device_room in autocreate?

[Pfriemler]

Einkanaler und Devices landen trotzdem in CUL_HM. Gibt es irgendeinen Grund dafür, den ich noch nicht verstanden habe?

[frank]

soweit ich weiss, arbeitet cul_hm ohne autocreate.
ich vermute, es gab zu viele user, die autocreate abgeschaltet hatten und dann über pairing probleme "jammerten". 

[Beta-User]

Zwischenzeitlich wieder: "arbeitete" statt "arbeitet", allerdings mit Einschränkungen... Und "autocreate" war mWn. noch nie für room bei den Unterkanälen zuständig, das kam afaik schon immer aus dem Modul selbst.

[Pfriemler]

Was es bisher machte, oder nicht machte, ist bekannt.
Dass es nicht über autocreate läuft, meinetwegen. Das interssiert einen User aber erst mal nicht. Er erwartet, dass sich seine neuen Geräte in einem bestimmten Raum versammeln, statt wie ohne autocreate sich über nach ihrer Hardware benamsten Räume zu verteilen.
Dennoch wäre es ein leichtes, ein vorhandenes Attribut zu berücksichtigen - oder meinetwegen ein eigenes vorzusehen.
Ich bin garantiert nicht der Erste, der das vermisst...

[Beta-User]

Dass es nicht über autocreate läuft, meinetwegen.

Nicht stimmt halt nicht mehr zu 100%...

Das interssiert einen User aber erst mal nicht. Er erwartet, dass sich seine neuen Geräte in einem bestimmten Raum versammeln, statt wie ohne autocreate sich über nach ihrer Hardware benamsten Räume zu verteilen.

Na ja, bin da nicht komplett durch, meine aber (ohne Berücksichtigung von CUL_HM), dass der Raum sich teilweise auch nach dem richtet, was das jeweilige (Client-) Modul vorgibt; es gibt da anscheinend alle möglichen Varianten (ich habe das bisher aber auch nicht näher untersucht, weil neue Devices bei mir eh' händisch umsortiert werden...)

Dennoch wäre es ein leichtes, ein vorhandenes Attribut zu berücksichtigen - oder meinetwegen ein eigenes vorzusehen.
Ich bin garantiert nicht der Erste, der das vermisst...

feel free, Code-Vorschläge zu machen. Ich war erst mal "froh", dass die Zusammenarbeit mit "autocreate" erst mal prinzipiell wieder funktioniert und hatte das mit dem Raum wegen der bekannten Vorbehalte erst mal hintan gestellt . (So wie ich das im Kopf habe, muss man sich dann aber irgendwo merken, warum bzw. wie der autocreate-Prozess dann gestartet wird; ganz trivial war es jedenfalls eher nicht).

EDIT: Habe jetzt doch mal in den Code geschaut. Der "autocreate-autocreate"-Zweig hat in der Tat einen fest codierten Wert. Anbei der Versuch, das zu reparieren...
Da sind btw. noch ein paar andere von franks "flags" mit verarbeitet...

[Pfriemler]

... meine aber (ohne Berücksichtigung von CUL_HM), dass der Raum sich teilweise auch nach dem richtet, was das jeweilige (Client-) Modul vorgibt; ...

So kenne ich das eben auch: CUL_WS, CUL_TX, FS20, WMBUS, LaCrosse, ... legen eben eigene Räume an, berücksichtigen aber eben auch ein evtl gesetztes device_room. (bei ESPeasy bin ich nicht sicher).

(ich habe das bisher aber auch nicht näher untersucht, weil neue Devices bei mir eh' händisch umsortiert werden...)

Mache ich auch so. Meinen Raum "autocreated" gibt es nur wenn ein autocreate zugeschlagen hat. Damit sehe ich aber sofort wenn es Handlungsbedarf gibt. Übel ist, wenn wie vor etwa einem Jahr ein Nachbar 30 Fensterkontakte, 3 Displays und diverse Taster in Betrieb nimmt und jede config-Message all diese Geräte auch bei mir angelegt hat. Die landeten dann alle in CUL_HM munter zwischen meinen anderen teilweise noch nicht umbenannten Gerätschaften und fielen dann erst im configCheck auf als ungepairt. Ja, wie auch!

feel free, Code-Vorschläge zu machen.

Natürlich, und den Job hast Du mir ja gerade schon dankenswerter abgenommen. Ich wollte aber erst mal hier nur fragen, ob ich da einen Teil einer Diskussion verpasst habe oder ob es irgendein erklärtes Ziel oder eine Absicht war, dort diesen eigenen Stiefel zu gehen. (Wie auch gesagt: Warum Devices und Einkanaler in CUL_HM landen, channels aber in Unsorted, erschließt sich mir auch nicht bis jetzt).

Ich war erst mal "froh", dass die Zusammenarbeit mit "autocreate" erst mal prinzipiell wieder funktioniert und hatte das mit dem Raum wegen der bekannten Vorbehalte erst mal hintan gestellt

also doch 

[Beta-User]

(Wie auch gesagt: Warum Devices und Einkanaler in CUL_HM landen, channels aber in Unsorted, erschließt sich mir auch nicht bis jetzt).

"autocreate-autocreate" bekommt "nur" (wieder) mit, dass ein neues Gerät zu erstellen ist, jetzt faßt CUL_HM halt das room-Attribut nicht mehr an, wenn autocreate was dazu "wußte".
Gibt es ein define von einem Gerät, das zwingend Kanäle braucht, "merkt"  das CUL_HM dann, dass die (ggf. teilweise) nicht vorhanden sind, und legt die zwangsweise an, aber der Mechanismus dazu ist ganz woanders abgelegt.
Für "virtuals" z.B. in #5511, für "reguläre" während des Init-checks (und über Umwege wohl auch, wenn die Model-Info gesendet wird) in #7807 usw..

[Pfriemler]

Ich beginne immer besser zu verstehen, warum es nicht so einfach ist wie ich dachte ... 

[Beta-User]

Na ja, es ist halt eine "assynchrone" Kommunikation, alles kommt per Funk nur "stückchenweise" rein und muss dann abgeglichen werden mit dem, was schon bekannt ist.
"Nebenbei" muss man noch wissen, welche Funkschnippsel eigentlich welchen Zweck haben usw. usf.. Kurz: Der Code ist wirklich was für (echte) "Könner", und bei manchen "Problemchen" (insbesondere ggf. solchen, die der User erst verursacht...) stellt sich halt die Frage, ob es die wert sind, im Modul gelöst zu werden...
Hier könnte man zwar ggf. Prüfungen dafür einzubauen, oder eben dem User die Aufgabe zu überlassen, das dann so zu sortieren, wie er es haben will... Bin auch für letzeres...

[Pfriemler]

Na ja, es ist halt eine "assynchrone" Kommunikation, alles kommt per Funk nur "stückchenweise" rein und muss dann abgeglichen werden mit dem, was schon bekannt ist.

Jein. CUL_HM nutzt ja auch nur "offizielle" Routinen zum Anlegen eines Devices und zur room-Attributierung. Genau und nur an dieser Stelle braucht es die Abfrage bzw die Ergänzung des rooms in all den Fällen wo bisher nur CommandDefine aufgerufen wird. Das ist letztlich doch übersichtlich.

...stellt sich halt die Frage, ob es die wert sind, im Modul gelöst zu werden...
...Hier könnte man zwar ggf. Prüfungen dafür einzubauen, oder eben dem User die Aufgabe zu überlassen, das dann so zu sortieren, wie er es haben will... Bin auch für letzeres...

Doch, solche Sachen, finde ich, sollten die Module allesamt einheitlich lösen. Wenn ich ein "device" manuell definiere, sehe ich seine DEF unmittelbar im WebUI und kann direkt weiterarbeiten, Raum/Gruppen festlegen. DEF korrigieren etc. Ein hmPairForSec oder hmPairSerial erzeugt dagegen ein Gerät und ggf. Kanäle "versteckt" - und ich kann nicht einmal vorhersagen wie sie heißen, weil ich neuen Geräten ihre hmID nicht ansehen kann (im Gegensatz zur serialNr). Ich muss entweder meinen Raum CUL_HM gut kennen oder aber zwingend ins Log schauen, um zu schauen, was da jetzt neu angelegt wurde. Es wäre allenfalls ein Workaround, CUL_HM stattdessen freizuräumen, damit man neue DEFs dort sofort wiederfindet.

[Beta-User]

Jein. CUL_HM nutzt ja auch nur "offizielle" Routinen zum Anlegen eines Devices und zur room-Attributierung. Genau und nur an dieser Stelle braucht es die Abfrage bzw die Ergänzung des rooms in all den Fällen wo bisher nur CommandDefine aufgerufen wird. Das ist letztlich doch übersichtlich.

Na ja, autocreate arbeitet an der Stelle mit "wildcards" - zumindest die müßte man ggf. auch auflösen usw..

Doch, solche Sachen, finde ich, sollten die Module allesamt einheitlich lösen. Wenn ich ein "device" manuell definiere, sehe ich [...]

Den Wunsch kann ich durchaus nachvollziehen, aber bei CUL_HM ist es doch so, dass man die Querbeziehungen zwischen den Kanälen in der Detailansicht jedes der Kanal-Devices ohne weiteres sehen (und klicken) kann. Das "Problem" ist also nicht so groß, wie es hier gemacht wird, v.a. dann nicht (mehr), wenn der User-Wunsch betr. des autocreate-rooms berücksichtigt wird und zumindest das Hauptdevice da auftaucht.

Aber nochmal: feel free ...