OWServer/OWDevice nonblocking patch

[justme1968]

ja. das hatte ich vergessen zu schreiben. fhem.pl muss ausführbar sein.

hattest du im master noch andere/gleiche owserver/owdevice geräte wie in der sandbox?

wenn du testest am besten mit einem leeren fhem bzw. mindestens mit einem bei dem es noch keine anderen owserver/owdevice devices gibt. das problem ist hier das beim autocreate in der sandbox noch nicht geprüft wird ob es einen namenskonflikt mit einem device im master gibt. und dabei kann es dann passieren das im master das 'normale' owdevice läuft und in der sandbox auch noch mal. die beiden lassen sich dann nicht synchronisieren weil beide 'echte' devices sind.

ich hab im anderen thread die files noch mal aktualisiert so das der absturz nicht mehr passieren sollte.

wenn du noch nicht genug hast probiere es bitte noch mal.

gruss
  andre

[eldrik]

so schnell geb ich nicht auf

Also in meiner Master Fhem Instanz habe ich derzeit kein eigene OWServer/OWDevice Definition, diese werden über meine beiden lokalen fhem2fhem Instanzen (1x OG, 1x EG) via clonedummy und readingsproxy reingeholt und sind was den Namen anbelangt unterschiedlich zu den Devicenamen, die in den fhem2fhem Instanzen über das Autocreate angelegt werden.

Die fhem2fhem Instanz fürs EG hatte ich vorher auch für meine Tests und den exklusiven Zugriff auf den owserver Prozess auf dem entfernten raspberry entsprechend heruntergefahren.

Werde in Kürze erneut testen.

Greetz
Eldrik

[eldrik]

so auf ein neues

gleiches vorgehen wie beim ersten Test.

Ergebnis:

unter unsorted sind jetzt die OWServer Instanz sowie einige OWDevices durch das Autocreate angelegt worden, die meisten scheinen auch angelegt worden zu sein, werden mir jedoch nur über den Umweg über meine clonedummy Einträge angezeigt, sie tauchen danach im jeweiligen clonedummy unter "Probably associated with" auf jedoch nicht im Raum unsorted.

Mindestens zwei owdevices fehlen (DS2450, DS18B20) in Gänze.

Nun zum kuriosen, in der Hoffnung, die fehlenden Devices über ein reopen des OWServers zu erhalten, hatte ich danach nur noch "get" für die OWServer Instanz zur Verfügung und bei einem späteren Sprung in die OWServer Instanz war das "set" zwar wieder da, jedoch enthielt dieses nur noch 3 - 5 Optionen und einige davon waren Namenseinträge (soweit ich es gesehen habe auch keins der ursprünglich über set aufrufbaren Optionen) von OWDevice Geräten beim "get" waren die OWServer Einträge sowie das "reopen" vorhanden, das "devices" jedoch nicht als ob hier munter getauscht wurde 

Aktuell hängt die fhem Instanz wieder nachdem man bis zu 10 Minuten noch flüssig damit arbeiten konnte.

Ja ich habe weiterhin mit einer "vollen" fhem.cfg getestet 

Greetz
Eldrik

[justme1968]

warum es die probleme im fhemweb gibt weiss ich jetzt. da kommt eine antwort aus der sandbox aus dem tritt. da muss ich noch etwas am protokoll ändern damit das nicht passiert.

und ich muss einbauen das optional die get und set ? gecached werden. zur zeit werden die bei jedem seiten aufbau neu gesendet. das ist meist gar nicht nötig und wenn die sandboden so autonom wie möglich arbeiten sollen auch gar nicht sinnvoll.

kommt beides noch.


die fehlenden devices kann ich nicht reproduzieren. ich habe den verdacht das bei dir noch irgendetwas anderes in der installation dazwischen funkt.

aber das schaue ich mir auch mal an.

vielleicht kannst du mal mit einer 'nagten' fhem konfiguration nur das OWServer device in der sandbox anlegen und schauen ob es dann besser läuft.

bei mir läuft es stundenlang mit etwa 10 devices problemlos. aber nur mit wenig web und ganz ohne set.

gruss
  andre