FHEM2FHEM: ständiges neu Anlegen von devices (und allem was diese so mitbringen)

[chris1284]

Moin,

seit heute legt fhem immer wieder neu plots für meinen KS300 an:

Eventmonitor:

2014-07-14 18:07:38 Global global UNDEFINED KS300 KS300 1234
2014-07-14 18:07:38 Global global DEFINED FileLog_KS300
2014-07-14 18:07:38 Global global DEFINED SVG_KS300
2014-07-14 18:07:38 Global global DEFINED SVG_KS300_2
2014-07-14 18:07:38 Global global SAVE

Log:

Code Auswählen Erweitern

2014.07.14 18:05:05 2: autocreate: define FileLog_KS300 FileLog ./log/KS300-%Y.log KS300:T:.*
2014.07.14 18:05:05 2: autocreate: define SVG_KS300 SVG FileLog_KS300:temp4rain10:CURRENT
2014.07.14 18:05:05 2: autocreate: define SVG_KS300_2 SVG FileLog_KS300:hum6wind8:CURRENT
2014.07.14 18:07:38 2: autocreate: define FileLog_KS300 FileLog ./log/KS300-%Y.log KS300:T:.*
2014.07.14 18:07:38 2: autocreate: define SVG_KS300 SVG FileLog_KS300:temp4rain10:CURRENT
2014.07.14 18:07:38 2: autocreate: define SVG_KS300_2 SVG FileLog_KS300:hum6wind8:CURRENT

der ks300 ist aber bereits sehr lange definiert und ich hatte diese, für mich störenden, plots nach dem 1. autocreate gelöscht. nun war eine ganze zeit ruhe alles i.O. bis heute
ich betreibe einen 2. fhemserver der auch eine CUL im SLOWRF besitzt wie der erste. beide server sind per fhem2fhem im logmodus verbunden. (der erste logt den 2.)

der 2. server meldet zur gleichen Zeit im log

2014.07.14 18:03:19 1: CUL_WS UNDEFINED temp/hum sensor detected, code 1
2014.07.14 18:06:15 1: CUL_WS UNDEFINED temp/hum sensor detected, code 1
2014.07.14 18:09:12 1: CUL_WS UNDEFINED temp/hum sensor detected, code 1

und legt ihn auch nicht an weil autocreate deaktiviert ist.

ich denke durch das fhem2fhem wird der ks300 bei jedem (auf der 2. instanz ignorierten) kontakt auf der 1. instanz angelegt.
kann ich das verhindern ohne speziell in fhem2fhem die zu logenden devices oder autocreate umzukonfigurieren ?
macht das überhaupt sinn das nur durch das logen auf der hauptinstanz alle devices automatisch auch erstellt werden obwohl dies auf der 2. unterbunden inst?

[Puschel74]

Hallo,

autocreate kennt das Attribut ignoreTypes.

Ich hab das für meine S300TH so angelegt.

Code Auswählen Erweitern

attr autocreate ignoreTypes CUL_WS_.*
auf der Haupt-FHEM-Instanz.

Grüße

[chris1284]

das ist mir bekannt. um nicht alles einzeln eintragen zu müssen habe ich es ja auf disabled gesetzt (auf der 2. instanz). ich finde nur es kann nicht die endgültige lösung sein alle geräte die man so hat auf der 1. instanz auf ignore zu setzen, vor allem nicht wenn die devices an sich ja schon da sind und nur so kram wie die plots immer wieder neu gemacht werden. es wäre toll wenn fhem2fhem diese art von meldungen, die auf der remote-seite ignoriert werden, einfach nicht weiterleiten/berücksichtigen würde oder autocreate zeug von bereits erstellten devices nicht nachziehen würde.

des weiteren: das war bis vor 2 tagen noch nicht. kann sein das es mit dem gestrigen update gekommen ist... muss ich noch testen, backup ist ja vorhanden

[Puschel74]

Hallo,

die Logeinträge auf der Hauptinstanz sind mir auch geblieben:

2014.07.01 00:03:43 1: CUL_WS UNDEFINED temp/hum sensor detected, code 2
2014.07.01 00:04:46 1: CUL_WS UNDEFINED temp/hum sensor detected, code 3

Nur werden alle CUL_WS ignoriert.

Ich kann damit leben - wenn sich dein Vorschlag aber durchsetzt

es wäre toll wenn fhem2fhem diese art von meldungen, die auf der remote-seite ignoriert werden, einfach nicht weiterleiten/berücksichtigen würde oder autocreate zeug von bereits erstellten devices nicht nachziehen würde.

hätte ich auch nichts dagegen 

Grüße

[rudolfkoenig]

Eigentlich sollte man FHEM2FHEM in RAW Mode betreiben. Wenn das nicht geht, weil einige Modul-Autoren keinen Bock haben, das gewuenschte Modul fuer FHEM2FHEM:RAW anzupassen, dann sollte man als Benutzer darauf achten, dass alle empfangbaren Geraete auf allen per FHEM2FHEM:LOG verbundenen Instanzen mit dem gleichen Namen angelegt sind, damit die Nachrichten mit sinnvollen Namen ankommen. Wenn man nur was spezielles vom anderen FHEM empfangen will, dann kann man einen passenden Regexp basteln. Wenn das auch nicht passt, dann sollten beide Instanzen mit aktivierten autocreate betrieben werden. Logs/SVG auf einem der Instanzen kann man vermeiden, wenn man das autocreate filelog Attribut nicht setzt. Ich meine das reicht an Optionen.

das war bis vor 2 tagen noch nicht.

Wenn das stimmt, dann wuesste ich gerne welche FHEM Version vor 2 Tagen im Einsatz war, da ich es im Moment nicht vorstellen kann, welche Aendrung das bewirkt haben soll.

[chris1284]

Logs/SVG auf einem der Instanzen kann man vermeiden, wenn man das autocreate filelog Attribut nicht setzt.

bedeutet aber auch keine logs/svgs für neue geräte bei denen es erwünscht ist

sollte man als Benutzer darauf achten, dass alle empfangbaren Geraete auf allen per FHEM2FHEM:LOG verbundenen Instanzen mit dem gleichen Namen angelegt sind,

unschön und wie ich finde nur sinnvoll wenn man die devices auch auf jeder instanz benötigt.

mein problem sollte laut commandref mit fhem2fhem im log mode ja eigentlich gar nicht auftreten

Einschränkungen: die Geräte der remote Installation werden nicht lokal angelegt

da scheint die commandref ja dann falsch zu sein...

Wenn das stimmt, dann wuesste ich gerne welche FHEM Version vor 2 Tagen im Einsatz war, da ich es im Moment nicht vorstellen kann, welche Aendrung das bewirkt haben soll.

die aktuelle in der regel. fakt ist das bisher die plots nicht bei jedem kontakt per autocreate neu erstellt wurden wenn es das devices ks300 schon gab (lief so über monate ohne das die plots je wieder angelegt wurden). was geänder wurde ist lediglich eine cul im slowrf am remotesystem. was ja laut cmd-ref nichts im log mode machen sollte da ja die

Einschränkungen: die Geräte der remote Installation werden nicht lokal angelegt

sollte evtl die 2. cul auf der remoteinstanz den gleichen namen haben wie das io-dev auf der hauptinstanz?
werd ich heute nachmittag mal testen...

[rudolfkoenig]

bedeutet aber auch keine logs/svgs für neue geräte bei denen es erwünscht ist

Sinnvollerweise haelt man die Logs nur auf der "Haupt-FHEM-Instanz", insofern sollte das keine Einschraenkung sein.

Einschränkungen: die Geräte der remote Installation werden nicht lokal angelegt

Klar, aber deren Events werden (je nach regexp) weitergeleitet.