Seit gestern ständig neue Geräte

Begonnen von stromer-12, 09 März 2014, 09:43:41

Vorheriges Thema - Nächstes Thema

stromer-12

Seit gestern werden ständig neue CUL_WS auf einen nicht angeschlossenen Cuno erzeugt. Es existieren aber schon 8 CUL_WS Geräte.
FHEM (SVN) auf RPi1B mit HMser | ESPLink
FHEM (SVN) virtuell mit HMLAN | HMUSB | CUL

stromer-12

Außerdem wurden alle nicht mit iodev versehenen Geräte mit dem nicht vorhandenen Cul_1 versehen.
FHEM (SVN) auf RPi1B mit HMser | ESPLink
FHEM (SVN) virtuell mit HMLAN | HMUSB | CUL

rudolfkoenig

Ich meine das Problem gefixed zu haben, siehe http://forum.fhem.de/index.php?topic=21023.new;topicseen#new
Nach Einspielen des Updates muessen noch die CUL_WS IODev Attribute entfernt werden.

Cul_1 sollte aber vorhanden sein, uebernatuerliche Kraefte hat FHEM noch keine.

stromer-12

#3
Ich habe das Cul_1 nicht aus der fhem.cfg entfernt. Die neu angelegten CUL_WS_x Geräte werden nach dem löschen automatisch wieder angelegt mit

Internals:
   CFGFN     
   CODE       3
   CUL_0_MSGCNT 1
   CUL_0_RAWMSG K21408183
   CUL_0_RSSI -75
   CUL_0_TIME 2014-03-09 15:20:44
   DEF        3
   IODev      CUL_1
   LASTInputDev CUL_0
   MSGCNT     1
   NAME       CUL_WS_3
   NR         871
   STATE      T: 14.0  H: 83.8
   TYPE       CUL_WS
   corr1      0
   corr2      0
   corr3      0
   corr4      0
   Readings:
     2014-03-09 15:20:44   DEVFAMILY       WS300
     2014-03-09 15:20:44   DEVTYPE         S300TH
     2014-03-09 15:20:44   humidity        83.8
     2014-03-09 15:20:44   state           T: 14.0  H: 83.8
     2014-03-09 15:20:44   temperature     14.0
Attributes:
   room       z_New_Devices


Ich bin nicht vor Ort um den Cuno mit Strom zu versorgen.
FHEM (SVN) auf RPi1B mit HMser | ESPLink
FHEM (SVN) virtuell mit HMLAN | HMUSB | CUL

stromer-12

In den alten Geräten steht bei INTERNALS weiterhin als IODev CUL_1, auch nach einen reboot.

Internals:
   CFGFN      /usr/share/fhem/FHEM/cfg_Garten.cfg
   CODE       6
   DEF        6 0.4
   IODev      CUL_1
   NAME       ho.tls
   NR         313
   STATE      T: 15.4  H: 68.4 D: 9.6
   TYPE       CUL_WS
   corr1      0.4
   corr2      0
   corr3      0
   corr4      0
   Readings:
     2014-03-09 14:55:01   DEVFAMILY       WS300
     2014-03-09 14:55:01   DEVTYPE         S300TH
     2014-03-09 14:55:01   cloudbase       695.4
     2014-03-09 14:55:01   dewpoint        9.6
     2014-03-09 14:55:01   humidity        68.4
     2014-03-09 14:55:01   state           T: 15.4  H: 68.4
     2014-03-09 14:55:01   temperature     15.4
Attributes:
   alias      Hof
   device_timeout 45
   event-min-interval .*:850
   event-on-change-reading .*
   room       Werte_Klima,Heizung
   sortby     10
   userReadings cloudbase {(ReadingsVal($name,"temperature", 0)-ReadingsVal($name,"dewpoint",0))*122}
FHEM (SVN) auf RPi1B mit HMser | ESPLink
FHEM (SVN) virtuell mit HMLAN | HMUSB | CUL

rudolfkoenig

Das war frueher auch so, und ist irrelevant, solange das Attribut IODev nicht gesetzt ist.

stromer-12

Es werden aber solange autocreate aktiv ist ständig neue Geräte von CUL_WS_1 bis CUL_WS_7 mit IODev Cul_1  erstellt bzw bei deaktivierten autocreate erscheint im Log:

2014.03.09 16:58:08 1: CUL_WS UNDEFINED temp/hum sensor detected, code 4
2014.03.09 16:58:48 1: CUL_WS UNDEFINED temp/hum sensor detected, code 5
2014.03.09 16:58:58 1: CUL_WS UNDEFINED temp/hum sensor detected, code 7
FHEM (SVN) auf RPi1B mit HMser | ESPLink
FHEM (SVN) virtuell mit HMLAN | HMUSB | CUL

stromer-12

#7
Jetzt habe ich in jedes Gerät einmal als IODev den CUL_0 eingetragen, daraufhin wurde IODev in den INTERNALS auf CUL_0 geändert und es werden in den alten Geräten wieder Werte geloggt.
Löscht man IODev aber wird nach einen Reboot wieder CUL_1 als IODev eingetragen und nichts geht mehr.
Es geht doch wieder. obwohl als IODev jetzt wieder CUL_1 drinsteht.
FHEM (SVN) auf RPi1B mit HMser | ESPLink
FHEM (SVN) virtuell mit HMLAN | HMUSB | CUL

stromer-12

Die Log Einträge:

2014.03.09 17:09:50 1: CUL_WS UNDEFINED temp/hum sensor detected, code 4
2014.03.09 17:10:28 1: CUL_WS UNDEFINED temp/hum sensor detected, code 5
2014.03.09 17:23:11 0: Server shutdown

Sind erst nach einen dem einmaligen anlegen des IODev CUL_0 verschwunden.
FHEM (SVN) auf RPi1B mit HMser | ESPLink
FHEM (SVN) virtuell mit HMLAN | HMUSB | CUL

rudolfkoenig

Und Du bist sicher, dass:
- du Version 5175 von fhem.pl benutzt?
- alle CUL_WS IODev Attribute entfernt hast, und danach fhem.pl gestartet hast.

Wenn ja, was heisst "IODev" gesetzt?
Ich kann dein Problem mit der aktuellen fhem.pl nicht nachstellen, aber es ist gut zu erklaeren mit der alten Version.

stromer-12

Zitat von: rudolfkoenig am 09 März 2014, 17:53:18
Und Du bist sicher, dass:
- du Version 5175 von fhem.pl benutzt?
ja, # $Id: fhem.pl 5175 2014-03-09 12:31:07Z rudolfkoenig $
Zitat- alle CUL_WS IODev Attribute entfernt hast, und danach fhem.pl gestartet hast.

Ja, (autocreate aktiv) hatte alle IODev's in den alten Geräten deaktiviert und die neu erzeugten Geräte gelöscht.
Nach speichern und anschliessenden Reboot hat er neue Geräte erzeugt.

2014.03.09 15:31:09 1: CUL_WS UNDEFINED temp/hum sensor detected, code 1
2014.03.09 15:31:09 2: autocreate: define CUL_WS_1 CUL_WS 1
2014.03.09 15:31:09 2: autocreate: define FileLog_CUL_WS_1 FileLog /var/log/fhem/CUL_WS_1-%Y.log CUL_WS_1:T:.*
2014.03.09 15:31:09 2: autocreate: define SVG_CUL_WS_1 SVG FileLog_CUL_WS_1:temp4hum6:CURRENT
2014.03.09 15:38:20 1: CUL_WS UNDEFINED temp/hum sensor detected, code 3
2014.03.09 15:38:21 2: autocreate: define CUL_WS_3 CUL_WS 3
2014.03.09 15:38:21 2: autocreate: define FileLog_CUL_WS_3 FileLog /var/log/fhem/CUL_WS_3-%Y.log CUL_WS_3:T:.*
2014.03.09 15:38:21 2: autocreate: define SVG_CUL_WS_3 SVG FileLog_CUL_WS_3:temp4hum6:CURRENT
2014.03.09 15:45:54 1: CUL_WS UNDEFINED temp/hum sensor detected, code 1
2014.03.09 15:47:08 1: CUL_WS UNDEFINED temp/hum sensor detected, code 3
2014.03.09 15:48:48 1: CUL_WS UNDEFINED temp/hum sensor detected, code 5
2014.03.09 15:48:51 1: CUL_WS UNDEFINED temp/hum sensor detected, code 1

Anschliessend mal autocreate deaktiviert, alle neuen Geräte gelöscht und in den alten IODev auf CUL_0 gesetzt. Danach war der Spuck vorbei.
Als alle Geräte dann das LASTInputDev CUL_0 hatten, läuft es jetzt auch ohne Angabe des IODev.

ZitatWenn ja, was heisst "IODev" gesetzt?
Ich kann dein Problem mit der aktuellen fhem.pl nicht nachstellen, aber es ist gut zu erklaeren mit der alten Version.
Internals:
   CFGFN      /usr/share/fhem/FHEM/cfg_Garten.cfg
   CODE       6
   CUL_0_MSGCNT 25
   CUL_0_RAWMSG K51984070
   CUL_0_RSSI -66.5
   CUL_0_TIME 2014-03-09 18:38:55
   DEF        6 0.4
   HEALTH_MONITORED_BY devicecheck
   HEALTH_STATE alive
   HEALTH_TIME 2014-03-09 18:38:55
   IODev      CUL_1
   LASTInputDev CUL_0
   MSGCNT     25
   NAME       ho.tls
   NR         313
   STATE      T: 10.2  H: 70.4 D: 5.1
   TYPE       CUL_WS
   corr1      0.4
   corr2      0
   corr3      0
   corr4      0
   Readings:
     2014-03-09 18:38:55   DEVFAMILY       WS300
     2014-03-09 18:38:55   DEVTYPE         S300TH
     2014-03-09 18:38:55   dewpoint        5.1
     2014-03-09 18:38:55   humidity        70.4
     2014-03-09 18:38:55   state           T: 10.2  H: 70.4
     2014-03-09 18:38:55   temperature     10.2
Attributes:
   alias      Hof
   device_timeout 45
   event-min-interval .*:850
   event-on-change-reading .*
   room       Werte_Klima,Heizung
   sortby     10

FHEM (SVN) auf RPi1B mit HMser | ESPLink
FHEM (SVN) virtuell mit HMLAN | HMUSB | CUL

stromer-12

Ich habe nochmal neu gestartet, und es geht immer noch, obwohl das LASTInputDev ja erst später erzeugt wird. Ich habe wohl vorhin zwischendurch was falsch gemacht.
FHEM (SVN) auf RPi1B mit HMser | ESPLink
FHEM (SVN) virtuell mit HMLAN | HMUSB | CUL