Fehler in 21_OWSWITCH.pm

[Medel]

Hallo,

beim abfragen von den einzelnen Eingängen z. B.:

Code Auswählen Erweitern

get Schalter input A
erhalte ich die Fehlermeldung:

Code Auswählen Erweitern

OWSWITCH: Get with wrong IODev type OWServer
hier meine definition:

Code Auswählen Erweitern

define myowserver OWServer 127.0.0.1:4304
define Schalter OWSWITCH 29.37AB17000000 60
attr Schalter IODev myowserver
attr Schalter model DS2408

Fehler vermutlich in Zeile 550

Code Auswählen Erweitern


527 #-- get single state
...
549 #-- OWFS interface
550 }elsif( $interface eq "OWFS" ){
551 $ret = OWFSSWITCH_GetState($hash);

mit

Code Auswählen Erweitern


550 }elsif( $interface eq "OWServer" ){

funktioniert es

[Markus Bloch]

Falscher Forumsbereich, siehe allerallerersten Thread!

[Prof. Dr. Peter Henning]

Hier richtiger Forumsbereich.

Fehler ist behoben, aktualisierte Version eingecheckt. Ist morgen im Update.

Edit: Nix "morgen" - OWSWITCH hat noch diverse andere Modifikationen auf Grund weiter gehender Anpassungen an das neue asynchrone OWX. Kommt irgendwann in den nächsten Tagen.

LG

pah

[Bartimaus]

Guten Morgen,

ich verwende OWSWITCH(version => 6.02) via OWX_ASYNC mit einem DS2413/Reedkontakt um den Zustand meines Garagentors und an einem DS2413 mittels Relais um meinen Ölbrenner zu loggen.

Das funktioniert auch prächtig seit 1,5 Jahren.

Gestern habe ich FHEM auf 5.8 aktualisiert, incl. aller Module. (OWSWITCH) wurde dabei auch aktualisiert.

Heute morgen stellte ich fest, das das loggen über beide DS2413 nicht mehr funktionierte. Alle anderen verwendeten 1wireModule liefen nach dem Update korrekt. (OWAD,OWMULTI,OWTHERM,OWCOUNT)

Backup wieder eingespielt, alles wieder ok.

Nur zur Info falls den Modulautor(pah) dies interressiert. Für weitere Infos stehe ich gerne zur Verfügung

Schönen Sonntag noch

[Prof. Dr. Peter Henning]

Kann ich nicht nachvollziehen. Aber, bitte gern zum Austesten hier die allerneuste Version von OWSWITCH.

Läuft synchron, asynchron, unter 5.8 und 5.7

LG

pah

[Bartimaus]

Dankeee

[Bartimaus]

Nabend,

sorry, die neue Version funktioniert leider auch nicht in meiner Konfiguration.
Alte Version wieder eingespielt, funktioniert wieder.
Liegts vielleicht an OWX_ASYNC ?

LG

[Prof. Dr. Peter Henning]

Möglich. Nicht meine Baustelle.

LG

pah

[Bartimaus]

Aber in der alten Version muss doch ein "Codeschnipsel" enthalten gewesen sein, der den Betrieb unter OWX_ASYNC möglich gemacht hat....

[Prof. Dr. Peter Henning]

Der ist auch unverändert in der neuen Version drin. Wird allerdings herausfliegen, wenn die asynchrone OWX-Version ohne Macken läuft (NICHT OWX_ASYNC).

Lösungsvorschlag: Alte Version installiert lassen und vom Update ausschließen.

LG

pah

[Bartimaus]

Yep, so habe ich es gemacht.

Leider stürzt FHEM bei mir gnadenlos ab, wenn ich den 1wireUsb ä-Busmaster mit OWX statt OWX_ASYNC konfiguriere

[Prof. Dr. Peter Henning]

Mit welchen Fehlermeldungen ?
Welche Version von OWX ?

LG

pah

[Bartimaus]

Vorgängerversion der aktuellen Version.
Bin zzt unterwegs und kann die VersNr nicht auslesen.

Keine Fehlermeldung im Webinterface. Harter Absturz von FHEM. Neustart nicht möglich.

Hatte wie folgt probiert:
1wUSBDevice im Webinterface gelöscht, und unter gleichem Namen mit OWX versucht neu anzulegen = Absturz.
Alternativ FHEM beendet, mit Nano die FHEM.cfg editiert (OWX statt OWX_ASYC) = FHEM startet nicht.

Mit der neuen Version nach Update noch nicht probiert. Ich probiere auch mal einen neuen Namen des Devices.

[Bartimaus]

"Fehler" gefunden.
Ich darf das Device (DS2480) nicht versuchen unter gleichem Devicenamen von OWX_ASYNC auf OWX umzuhängen, dann schepperts. Der Devicename muss geändert werden...

[Prof. Dr. Peter Henning]

Das ist in der Tat ein subtiles Problem, dessen Ursache noch nicht klar ist. Mal sehen, ob ich das irgendwie beim Start des OWX-Modul sabfangen kann.

LG

pah

[ext23]

Bei mir hat es geklappt, ich habe es direkt in der config geändert, dann noch alles was das Interface betrifft aus der fhem.save gelöscht und neu gestartet.

/Daniel

[Bartimaus]

Der "Fehler" ist aber nicht neu, in der Vorgängerversion war er auch drin.

Als ich gestern das umgestellt/getestet habe, waren nach einem Neustart natürlich alle Zuordnungen von den Geräten futsch die an diesem Bus hängen. D.h. alle meldeten sich in FHEM brav mit Ihrer ID als Devicenamen neu an.

Hab dann kurzerhand alles wieder zurückgedreht und Backup eingespielt.

[Prof. Dr. Peter Henning]

Interface betrifft aus der fhem.save gelöscht

Tja, irgendetwas geht da noch durcheinander, wenn man das einfach statt eines alten Moduls einsetzt. Hat genau mit den Save-Daten zu tun, aber ich habs noch nicht gefunden.

LG

pah

[Bartimaus]

Aber der normale Prozess beim löschen eines Devices ist ja nicht, das der Anwender händisch die fhem.save editiert...., sollte zumindet nicht so sein....

[ext23]

Aber der normale Prozess beim löschen eines Devices ist ja nicht, das der Anwender händisch die fhem.save editiert...., sollte zumindet nicht so sein....

Nee, ich hab das auch nur gemacht weil ich gesehen habe, dass es Probleme gibt und die fhem.save hatte ich da noch im Hinterkopf. Ich hab die Datei sonst auch noch nie angefasst. Nur erschien es mir hier logisch bei dem Fehler dort mal rein zu schauen. Woanders speichert FHEM ja eigentlich nichts. Ob das jetzt wirklich der Grund war, dass es bei mir geklappt hat oO

/Daniel