Hallo,
beim abfragen von den einzelnen Eingängen z. B.:
get Schalter input A
erhalte ich die Fehlermeldung:
OWSWITCH: Get with wrong IODev type OWServer
hier meine definition:
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
527 #-- get single state
...
549 #-- OWFS interface
550 }elsif( $interface eq "OWFS" ){
551 $ret = OWFSSWITCH_GetState($hash);
mit
550 }elsif( $interface eq "OWServer" ){
funktioniert es
Falscher Forumsbereich, siehe allerallerersten Thread!
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
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
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
Dankeee ;)
Nabend,
sorry, die neue Version funktioniert leider auch nicht in meiner Konfiguration.
Alte Version wieder eingespielt, funktioniert wieder.
Liegts vielleicht an OWX_ASYNC ?
LG
Möglich. Nicht meine Baustelle.
LG
pah
Aber in der alten Version muss doch ein "Codeschnipsel" enthalten gewesen sein, der den Betrieb unter OWX_ASYNC möglich gemacht hat.... ::)
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
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
Mit welchen Fehlermeldungen ?
Welche Version von OWX ?
LG
pah
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.
"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...
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
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
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.
ZitatInterface 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
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.... ::)
Zitat von: Bartimaus am 23 März 2017, 12:34:34
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