mir ist gerade aufgefallen das OWDevice_Define beim anlegen d.h. auch beim neustart von fhem alle möglichen readings ausliest und aktualisiert auch wenn sie in polls nicht mit angegeben sind.
die einfachste art das zu beheben wäre am ende von OWDevice_Define nicht OWDevice_UpdateValues aufzurufen sondern erst per notify an global:INITIALIZED. zu diesem zeitpunkt wären nach einem neustart dann auch alle attribute (und eben auch polls) gesetzt.
gruss
andre
Zitat von: justme1968 schrieb am So, 15 September 2013 23:46mir ist gerade aufgefallen das OWDevice_Define beim anlegen d.h. auch beim neustart von fhem alle möglichen readings ausliest und aktualisiert auch wenn sie in polls nicht mit angegeben sind.
die einfachste art das zu beheben wäre am ende von OWDevice_Define nicht OWDevice_UpdateValues aufzurufen sondern erst per notify an global:INITIALIZED. zu diesem zeitpunkt wären nach einem neustart dann auch alle attribute (und eben auch polls) gesetzt.
Ich bin einem Patch, der das wie von Dir beschrieben ändert, aufgeschlossen. Für eine aktive Entwicklung fehlt mir derzeit die Zeit.
Viele Grüße
Boris
mache ich fertig.
gruss
andre
mir ist grad aufgefallen das ich den patch noch nicht gepostet hatte.
damit wird:
- der ingternal timer im define entfernt. das verhindert das bei einem modify timer plötzlich mehrfach da sind
- das erste OWDevice_UpdateValues nach global:INITIALIZED verschoben. dann ist polls schon gesetzt
gruss
andre
Zitat von: justme1968 am 23 November 2013, 14:16:20
mir ist grad aufgefallen das ich den patch noch nicht gepostet hatte.
Danke, wird gleich eingecheckt.
Boris
Hallo zusammen
Ich habe heute das Update aktualisiert und dabei festgestellt, dass beim einem "shutdown restart" von FHEM der Status meiner iButtons beim initialisieren kurz "present 0" danach wieder auf "present 1" wechseln. Das bewirkt bei mir, dass FHEM meint ich hätte das Haus verlassen die Rollladen nach unten gehen (je nach Dämmerung) und danach wieder nach oben. Gibt es für mein Problem eine Lösung? Ich habe folgende Definition:
define OWFS1 OWServer 192.168.2.5:4304
attr OWFS1 nonblocking 1
define Busmaster1 OWDevice 81.598341000000
attr Busmaster1 comment Presence_Schluesselbretter_LCD_Displays
attr Busmaster1 model DS1420
attr Busmaster1 room Deamon
define ibutton_Dani OWDevice 01.684A8A150000 4
attr ibutton_Dani IODev OWFS1
attr ibutton_Dani comment Owner_Dani
attr ibutton_Dani event-on-change-reading present
attr ibutton_Dani model DS2401
attr ibutton_Dani room Presence
Herzlichen Dank für die Hilfe.
Gruss Dani
Hallo Dani,
das hängt mit Sicherheit mit einem der Patches zusammen, die ich gestern eingespielt habe.
Ich muß leider gleich aus dem Haus und bin erst wieder nächstes Wochenende zurück und in der Lage, den Kode anzufassen.
André, hast Du eine Chance, der Ursache nachzugehen?
Viele Grüße
Boris
ich schaue es mir nachher gleich mal an.
die patches von gestern waren:
- temperatur auflösung -> das ist es sicher nicht
- autocreate -> das kann es eigentlich nicht sein
- nur noch auslesen was in polls steht -> das sollte nur weniger readings erzeugen. niemals falsche -> vielleicht ein seltsamer seiteneffekt?
vielleicht kannst du mal verbose auf 5 setzen (und speichern) und dann ein neustart loggen.
eine idee: wann hattest du das letzte save vor dem neustart gemacht? kann es sein das sie 0 nicht vom bus gekommen ist sondern aus dem save file?
gruss
andre
Hallo Andre
Danke für deine Unterstützung.
Zitatvielleicht kannst du mal verbose auf 5 setzen (und speichern) und dann ein neustart loggen.
Das Log habe ich dir per PM gesendet.
Zitateine idee: wann hattest du das letzte save vor dem neustart gemacht? kann es sein das sie 0 nicht vom bus gekommen ist sondern aus dem save file?
Nein, ich hatte keinen save gemacht (habe ich auch nichts geändert), auch wenn ich einen mache, beobachte ich das gleiche Verhalten.
Gruss Dani
ich hab das problem gefunden. es hängt mit den namen der devices zusammen und der reihenfolge in der das global::INITIALIZED notify aufgerufen wird. das hat dazu geführt das die devices gelesen wurden bevor der server sich verbunden hatte und keine werte zurück gekommen sind. wenn man die reihenfolge fest vorgibt geht alles.
anbei die beiden module jeweils komplett und als patch.
@borris: möchtest du es selber einchecken?
gruss
andre
Hallo Andre
Besten Dank für die Analyse und Korrektur der Module. Ich habe sie eingespielt und getestet und kann bestätigen, dass das Problem gefixt ist!
Nochmasl Danke! Gruss Dani
Zitat von: justme1968 am 24 November 2013, 23:38:44
anbei die beiden module jeweils komplett und als patch.
@borris: möchtest du es selber einchecken?
Herzlichen Dank, Andre!
Ich bin einverstanden, daß Du die Änderungen ausnahmsweise eincheckst, damit die Anwender den Fix gleich haben.
Viele Grüße
Boris
ist eingecheckt.
gruss
andre
Hi,
bei mir wird nach dem Update der STATE, der über das Netzwerk abzufragende OWServer nicht mehr angezeigt es erscheint nur ???, mache ich ein get devices auf einen der OWServer stürzt FHEM ab und lässt sich nur über fhem start wieder starten.
Die lokale OWServer Installation auf meinem FHEM Host ist davon ausgenommen.
Greetz
Eldrik
arg... sorry.
bei mehr als einem server wurde nur einer aber dafür mehrfach initialisiert.
ich hab es eben repariert und eingecheckt.
bis das update da ist kannst du in 10_OWServer.pm von hand Zeile 217OWServer_OpenDev($hash);
inOWServer_OpenDev($defs{$d});
ändern.
gruss
andre
besser ;)
Greetz
Eldrik
Hm, komisch.... gestern nach dem Update wurde mein zweiter OWServer nicht mehr initialisiert. Ist mir aber erst heute Morgen aufgefallen.
Der Server selber lief problemlos, aber erst ein reopen in fhem hat das Problem beseitigt.
Zufall oder hat sich da was verschlimmbessert? ;-)
VG
Ralf
siehe oben. ist schon gefixt und im update von heute.
gruss
andre
Mist, überlesen.
Danke andre!
VG
Ralf
PS:
Dafür gibt es jetzt aber gleich mehrfach beim fhem-start
Use of uninitialized value in split at ./FHEM/10_OWServer.pm line 358.
Use of uninitialized value in split at ./FHEM/10_OWServer.pm line 332.
Use of uninitialized value in split at ./FHEM/10_OWServer.pm line 332.
Use of uninitialized value in split at ./FHEM/10_OWServer.pm line 332.
Use of uninitialized value in split at ./FHEM/10_OWServer.pm line 332.
Use of uninitialized value in split at ./FHEM/10_OWServer.pm line 332.
Use of uninitialized value in split at ./FHEM/10_OWServer.pm line 332.
Use of uninitialized value in split at ./FHEM/10_OWServer.pm line 332.
Use of uninitialized value in split at ./FHEM/10_OWServer.pm line 332.
Use of uninitialized value in split at ./FHEM/10_OWServer.pm line 332.
Use of uninitialized value in split at ./FHEM/10_OWServer.pm line 332.
Use of uninitialized value in split at ./FHEM/10_OWServer.pm line 332.
Use of uninitialized value in split at ./FHEM/10_OWServer.pm line 332.
Use of uninitialized value in split at ./FHEM/10_OWServer.pm line 332.
Genau genommen werden alle OW Server wohl erst recht spät initialisiert....
2013.11.26 08:01:01 1: Including fhem.cfg
2013.11.26 08:01:02 3: tPort: port 7072 opened
2013.11.26 08:01:03 3: WEB: port 8083 opened
2013.11.26 08:01:03 3: WEBphone: port 8084 opened
2013.11.26 08:01:03 3: WEBtablet: port 8085 opened
2013.11.26 08:01:04 3: Opening CUL_Casa device /dev/ttyACM0
2013.11.26 08:01:04 3: Setting CUL_Casa baudrate to 9600
2013.11.26 08:01:04 3: CUL_Casa device opened
2013.11.26 08:01:04 3: CUL_Casa: Possible commands: BCFiAGMRTVWXefmltux
2013.11.26 08:01:04 3: Opening CUNO_MansCave device 192.168.1.14:2323
2013.11.26 08:01:04 3: CUNO_MansCave device opened
2013.11.26 08:01:04 3: CUNO_MansCave: Possible commands: mBCFiAIGMRTVWXOefltuxEcq
2013.11.26 08:01:05 1: HMLAN_Parse: HMLAN_Casa new condition disconnected
2013.11.26 08:01:05 3: Opening HMLAN_Casa device 192.168.1.27:1000
2013.11.26 08:01:05 3: HMLAN_Casa device opened
2013.11.26 08:01:05 1: HMLAN_Parse: HMLAN_Casa new condition init
2013.11.26 08:01:10 3: OW_Casa_LCD: reading type did not return a value
2013.11.26 08:01:10 3: OW_TankSensor: reading type did not return a value
2013.11.26 08:01:10 3: Weinkeller: reading type did not return a value
2013.11.26 08:01:10 3: Heizungsraum: reading type did not return a value
2013.11.26 08:01:10 3: Heizung_Vorlauf: reading type did not return a value
2013.11.26 08:01:10 3: Heizung_Control: reading type did not return a value
2013.11.26 08:01:10 3: OW_TankControl: reading type did not return a value
2013.11.26 08:01:10 3: Serverschrank: reading type did not return a value
2013.11.26 08:01:10 3: OW_Counter: reading type did not return a value
2013.11.26 08:01:10 3: OW_Counter_Ralfs_Buero: reading type did not return a value
2013.11.26 08:01:10 3: OW_Counter_MansCave: reading type did not return a value
2013.11.26 08:01:10 3: MC_T_oben: reading type did not return a value
2013.11.26 08:01:10 3: MC_T_unten: reading type did not return a value
2013.11.26 08:01:10 3: Aussentemp: reading type did not return a value
2013.11.26 08:01:10 3: MC_Control: reading type did not return a value
2013.11.26 08:01:11 1: Including ./log/fhem.save
2013.11.26 08:01:14 3: Heizungsraum: reading temperature did not return a value
2013.11.26 08:01:14 3: MC_T_unten: reading temperature did not return a value
2013.11.26 08:01:14 3: Serverschrank: reading temperature did not return a value
2013.11.26 08:01:14 3: MC_Control: reading sensed.A did not return a value
2013.11.26 08:01:14 3: MC_Control: reading sensed.B did not return a value
2013.11.26 08:01:14 3: Heizung_Control: reading sensed.A did not return a value
2013.11.26 08:01:14 3: Heizung_Control: reading sensed.B did not return a value
2013.11.26 08:01:14 3: Weinkeller: reading temperature did not return a value
2013.11.26 08:01:14 3: OW_Counter: reading counters.A did not return a value
2013.11.26 08:01:14 3: OW_Counter: reading counters.B did not return a value
2013.11.26 08:01:14 3: MC_T_oben: reading temperature did not return a value
2013.11.26 08:01:14 3: OW_TankSensor: reading volt.A did not return a value
2013.11.26 08:01:14 3: OW_TankSensor: reading volt.B did not return a value
2013.11.26 08:01:14 3: OW_Counter_Ralfs_Buero: reading counters.A did not return a value
2013.11.26 08:01:14 3: Heizung_Vorlauf: reading temperature did not return a value
2013.11.26 08:01:14 3: OW_Counter_MansCave: reading counters.A did not return a value
2013.11.26 08:01:15 3: Aussentemp: reading temperature did not return a value
2013.11.26 08:01:15 3: OWS_Casa: Opening connection to OWServer 192.168.1.18:4304...
2013.11.26 08:01:15 3: OWS_Casa: Successfully connected to 192.168.1.18:4304.
2013.11.26 08:01:15 3: OWS_Casa: Opening connection to OWServer 192.168.1.18:4304...
2013.11.26 08:01:15 3: OWS_Casa: Successfully connected to 192.168.1.18:4304.