OWX New Generation

[Prof. Dr. Peter Henning]

Seit einigen Tagen sind die komplett überarbeiteten Versionen der OWX-Frontendmodule in der Distribution. Bitte alle unerwünschten Effekte hier posten.

LG

pah

[ext23]

Hallo,

danke erst mal für die neuen Module. Ich nutze vorwiegend OWLCD und OWID für meine iButtons. Im Prinzip läuft alles wie vorher. Lediglich beim OWLCD kommt es zunehmend vor, dass die GPIO Ports nicht richtig gesetzt werden. Das war auch früher schon ab und an mal, aber es hat definitiv zugenommen.

Also Feature Request steht immer noch die Bitte an, LCD ChipTyp und die  Abteilung "#-- replace umlaut chars for special codepage" im Modul durch Attribute zu ersetzen.
Zum einen ist das Bequemlichkeit, ja, aber schlimmer ist, dass durch meine Änderungen mir jeden Tag ein Update des OWLCD vorgeschlagen wird und zweitens (noch schlimmer) wenn man aus versehen FHEM mit falschem ChipTyp startet, ich die ganzen Gurke stromlos machen muss da sich das LCD komplett verabschiedet hat.

Gruß
Daniel

[sentinel1]

Hallo,

ich wollte OWID testen mit iButtons aber ich kann nicht "event-on-change-reading" benutzen,es steht in eine reihe mit "interval".Ich habe dann "attr intervalevent-on-change-reading".
Liegt es an OWID oder mache ich was falsch?

Gruß,
Claudiu

[marc2]

Moin !

Der dougie-counter läuft bei mir mit OWX_ASYNC ansich wunderbar. Allerdings nur, wenn noch ein weiterer
1w Sensor am Bus hängt (z.B. ein DS18S20). Hängt er allein am Bus wir er nicht erkannt

Code Auswählen Erweitern

2016.04.01 00:12:21 5: OWX_ASYNC_Schedule master: OWHAR, task: OWHAR
2016.04.01 00:12:21 2: OWX: 1-Wire devices found on bus OWHAR ()
2016.04.01 00:12:21 4: OWX_ASYNC_RunTasks: OWHAR task exited: OWX: 1-Wire devices found on bus OWHAR

Hängt der DS18S20 mit am Bus, dann klappt es sofort wieder:

Code Auswählen Erweitern

2016.04.01 00:13:32 5: OWX_ASYNC_Schedule master: OWHAR, task: OWHAR
2016.04.01 00:13:32 2: OWX: 1-Wire devices found on bus OWHAR (Thermometer_HAR2,gaszaehler)
2016.04.01 00:13:32 4: OWX_ASYNC_RunTasks: OWHAR task exited: OWX: 1-Wire devices found on bus OWHAR
10.20A48C020800      DS18S20/DS1920 Thermometer_HAR2
1D.A2D984000002      DS2423         gaszaehler

Ich bin mir nicht sicher, ob jemals ging, aber hat jemand ein vergleichbares Problem ?

Danke & GRuß, Marc

[Prof. Dr. Peter Henning]

@sentinal: Falscher Thread. Bitte Anfängerdokumentation lesen.

LG

pah

[cwagner]

Guten Tag,

diese Beobachtung mache ich mit den neuen Modulen bei jedem Neustart meines FHEM
2016.04.02 10:40:36 1: PERL WARNING: substr outside of string at ./FHEM/21_OWSWITCH.pm line 1019.
2016.04.02 10:40:36 1: PERL WARNING: Use of uninitialized value $res in numeric ne (!=) at ./FHEM/21_OWSWITCH.pm line 1146.
2016.04.02 10:40:36 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/21_OWSWITCH.pm line 1147.

eingesetzte Versionen:
21_OWSWITCH.pm      11130 2016-03-27 09:14:38Z pahenning
# $Id: 00_OWX.pm 2016-03 pahenning $
# $Id: 11_OWX_SER.pm 2016-02 - pahenning $

Ist es richtig, dass 00_OWX und 11_OWX_SER aus dem "Tester gesucht"-Thread benutzt werden müssen?


Herzliche Grüße

Christian

[locutus]

Mir fällt auf, dass das neue OWCOUNT Modul aus der DS2423 Emulation auf ATtiny einen DS2423eold macht. Manuelle Änderung der Attribute zum DS2423enew ist praktisch wirkungslos.

[Prof. Dr. Peter Henning]

@cwagber: Nein. Sollte mit dem standardmäßig verteilten OWX funktionieren - das neue kann eben "asynchron". Dauert aber noch etwas...

@locutus: Kommt darauf an. Hat der Emulator interne Memory-Pages 0..15 ?

LG

pah

[UweH]

Moin,

folgendes Problem ist auf zwei FHEM-Installationen aufgetreten: Nach dem ersten Update nach der Freigabe der OWX-Module wird 00_OWX.pm nach dem Shutdown Restart nicht geladen. Nach dem Einspielen der OWX-Version 6.0alpha8 lief es dann wieder. Bei der Versions-Abfrage in FHEM fällt auf, dass die 00_OWX_TCP.pm
noch eine Testversion ist

Code Auswählen Erweitern

21_OWAD.pm               11130 2016-03-27 09:14:38Z pahenning
21_OWCOUNT.pm            11130 2016-03-27 09:14:38Z pahenning
21_OWID.pm               11130 2016-03-27 09:14:38Z pahenning
21_OWLCD.pm              11130 2016-03-27 09:14:38Z pahenning
21_OWMULTI.pm            11130 2016-03-27 09:14:38Z pahenning
21_OWSWITCH.pm           11130 2016-03-27 09:14:38Z pahenning
21_OWTHERM.pm            11130 2016-03-27 09:14:38Z pahenning
21_OWVAR.pm              11131 2016-03-27 09:16:56Z pahenning
# $Id: 00_OWX.pm 2016-03 pahenning $
# $Id: 11_OWX_TCP.pm 2015-03 - pahenning $

Die LAN-Busmaster werden nicht erkannt, folgende Meldungen dazu bekomme ich:

Code Auswählen Erweitern

2016.04.03 09:26:00 1: OWX: COC/CUNO device 192.168.xxx.xx:26 not defined
2016.04.03 09:26:00 1: define 1wire_Haus_1 OWX 192.168.xxx.xx:26: OWX: COC/CUNO device 192.168.178.37:26 not defined
2016.04.03 09:26:00 1: OWX: COC/CUNO device 192.168.xxx.xx:23 not defined
2016.04.03 09:26:00 1: define 1wire_Haus_2 OWX 192.168.xxx.xx:23: OWX: COC/CUNO device 192.168.178.40:23 not defined
2016.04.03 09:26:00 1: OWX: COC/CUNO device 192.168.xxx.xx:26 not defined
2016.04.03 09:26:00 1: define 1wire_Haus_3 OWX 192.168.xxx.xx:26: OWX: COC/CUNO device 192.168.178.40:26 not defined
2016.04.03 09:26:00 1: OWX: COC/CUNO device 192.168.xxx.xx:23 not defined
2016.04.03 09:26:00 1: define 1wire_GH OWX 192.168.xxx.xx:23: OWX: COC/CUNO device 192.168.178.65:23 not defined
2016.04.03 09:26:00 1: OWX: COC/CUNO device 192.168.xxx.xx:23 not defined
2016.04.03 09:26:00 1: define 1wire_Garage OWX 192.168.xxx.xx:23: OWX: COC/CUNO device 192.168.178.27:23 not define

Das Problem ist reproduzierbar.

Gruß
Uwe

[Prof. Dr. Peter Henning]

Das per update verteilte OWX ist tatsächlich eine sehr alte Version, die mit dem OWX_TCP.pm gar nicht zusammenarbeitet. Dafür hatte ich damals immer socat verwendet.

Wenn Du also TCP-Busmaster hast, kann ich für OWX  im Moment nur die alpha-Versionen aus dem "Tester gesucht" empfehlen. Bitte noch um etwas Geduld - immerhin werden hier zeitgleich 12 Module mit jeweils  im Mittel 2000 Codezeilen überarbeitet.

Erste Prio waren die Frontendmodule mit "alten" Standardinstallationen. Die laufen auch ohne Probleme, so wie ich das sehe.

LG

pah

[Achim]

Hallo,

ich habe heute bei einem "Update" von FHEM folgendes festgestellt. Folgende Events werden beim Update angezeigt:

2016-04-03 09:50:57 Global global ATTR OWX_Z1 model DS2423eold
2016-04-03 09:50:57 Global global ATTR OWX_Z1 nomemory 1
2016.04.03 09:50:58 2 : Backup with command: tar -cf .......
2016-04-03 09:51:57 Global global ATTR OWX_Z1 model DS2423eold
2016-04-03 09:51:57 Global global ATTR OWX_Z1 nomemory 1
2016.04.03 09:52:24 1 : backup tar: Removing leading `/' from member names tar: Removing leading `/' from hard link targets
2016.04.03 09:52:24 1 : backup done: FHEM-20160403_095058.tar.gz (13649384 Bytes)
2016.04.03 09:52:24 1 :
2016.04.03 09:52:24 1 : fhem
2016.04.03 09:52:24 1 : RMDIR: /usr/share/fhem/restoreDir/2016-03-24
2016.04.03 09:52:25 1 : UPD ./CHANGED
2016.04.03 09:52:25 1 : UPD ./fhem.pl

2016.04.03 09:52:44 1 : Calling /usr/bin/perl /usr/share/fhem/contrib/commandref_join.pl -noWarnings, this may take a while
2016-04-03 09:52:57 Global global ATTR OWX_Z1 model DS2423eold
2016-04-03 09:52:57 Global global ATTR OWX_Z1 nomemory 1
2016-04-03 09:53:57 Global global ATTR OWX_Z1 model DS2423eold
2016-04-03 09:53:57 Global global ATTR OWX_Z1 nomemory 1
2016-04-03 09:53:59 Global global ATTR OWX_Z2 model DS2423eold
2016-04-03 09:53:59 Global global ATTR OWX_Z2 nomemory 1
2016-04-03 09:54:57 Global global ATTR OWX_Z1 model DS2423eold
2016-04-03 09:54:57 Global global ATTR OWX_Z1 nomemory 1

Auch im Eventmonotor sind die Einträge "Global global ATTR OWX_Z1 nomemory 1" zu sehen:

2016-04-03 10:15:58 Global global ATTR OWX_Z2 model DS2423eold
2016-04-03 10:15:58 Global global ATTR OWX_Z2 nomemory 1
2016-04-03 10:15:58 OWCOUNT OWX_Z2 memory: no pages, no midnight
2016-04-03 10:15:58 OWCOUNT OWX_Z2 StromOG: 0.968
2016-04-03 10:15:58 OWCOUNT OWX_Z2 EnergieOG: 0.1445
2016-04-03 10:15:58 OWCOUNT OWX_Z2 StromEG: 2.3494
2016-04-03 10:15:58 OWCOUNT OWX_Z2 EnergieEG: 0.3215
2016-04-03 10:15:58 OWCOUNT OWX_Z2 StromOG: 0.968  kW EnergieOG: 0.144  kW/h StromEG: 2.349  kW EnergieEG: 0.322  kW/h

Für OWCOUNT verwende ich zwei alternative DS2423 Module mit der Firmware von Dirk, die er mit den Leiterpalten mit ausgeschickt hat. Die Definition in FHEM sieht folgendermaßen aus:

Code Auswählen Erweitern

define OWX_Z1 OWCOUNT DS2423eold A2D988000002 60
attr OWX_Z1 AFactor 0.01
attr OWX_Z1 AMode daily
attr OWX_Z1 AName Gas
attr OWX_Z1 AOffset 164403.0
attr OWX_Z1 ARate hour
attr OWX_Z1 AUnit m³
attr OWX_Z1 BFactor 0.01
attr OWX_Z1 BMode daily
attr OWX_Z1 BName Wasser
attr OWX_Z1 BRate hour
attr OWX_Z1 BUnit m³
attr OWX_Z1 IODev NANO1_D3
attr OWX_Z1 LogM FileLog_Gasverbrauch_Monat
attr OWX_Z1 LogY FileLog_Gasverbrauch_Jahr
attr OWX_Z1 model DS2423eold
attr OWX_Z1 nomemory 1
attr OWX_Z1 room UG_Treppe


Ansich nur ein "Schönheitsfehler" auf der Oberfläche, allerdings kann ich nicht beurteilen ob das Programm/Ablauftechnisch intern anders ist.

viele Grüße
Achim

[locutus]

Kommt darauf an. Hat der Emulator interne Memory-Pages 0..15 ?

Ja, der Memorypage Support 14 & 15 ist definitiv vorhanden.

[Prof. Dr. Peter Henning]

Der Test, ob die memory pages vorhanden (= schreibbar und lesbar !) sind, dauert relativ lange und musste an die neue interne Logik massiv angepasst werden. Hat offenbar in manchen Fällen noch so seine Probleme.

Ich werde also diesen Test kippen - er wird nur noch dann durchgeführt, wenn ein Device automatisch angelegt wurde und das Attribut "model" nicht manuell gesetzt worden ist.

LG

pah

[Achim]

Hallo,

bei OWCOUNT das Attribut "model" ist in der commandref nicht (mehr?) bei den Attributen beschrieben. Nur in der "Define" Sektion. Ist das so gewollt?

Viele Grüße
Achim

[UweH]

Bitte noch um etwas Geduld

Kein Problem, Danke für die Info.

Gruß
Uwe

[Prof. Dr. Peter Henning]

@ext23: Anbei eine Version, in der ein zusätzliches Attribut lcdcontroller gesetzt werden kann.

Codepage richtet sich nach dem controller, bitte mal testen, ob das so einfacher ist.

LG

pah

[ext23]

  my $attlist       = "IODev do_not_notify:0,1 showtime:0,1 ".
                      "lcdgeometry:0-32-64-96,0-64-20-84 lcdcontroller:KS0073,HD44780 ".
                      $readingFnAttributes;

Hinter das HD44780 muss ein Leerzeichen rein, sonst hat der das reading-on-change-event rann geklatscht.

Gruß
Daniel

[Prof. Dr. Peter Henning]

Nu ja. Leerzeichen werden ignoriert. Sonst wie gewünscht ?

Thema GPIO: Geht bei mir problemlos, habe auch keinen HD44780 zum Testen.

LG

pah

[ext23]

Thema GPIO: Geht bei mir problemlos, habe auch keinen HD44780 zum Testen.
pah

Komisch, das passiert bei mir auch so sporadisch, naja ich checke nochmal ob ich irgendwo noch ein Fehler habe der zufällig die Werte neu setzt. Aber dann müsste doch da ein system hinter sein mhh naja

Ansonsten passt das Modul so, also ich finde es gut so.

/Daniel

[cwagner]

Guten Tag, im Dauerbetrieb fiel mir nun doch eine Anomalie auf, die ich sofort beenden kann, wenn ich die alte 21_OWSWITCH (V. 5.22) wieder aktiviere.

Beim 2. und weiteren Schalten eines Kanals meines 8-Port-Switch (z.B. A, angesprochen als "Brenner") werden weitere Kanäle geschaltet. Ich füge mal eine kurze Session ein :

Code Auswählen Erweitern


2016-04-04 19:03:37 OWSWITCH Switch_Heizkeller Brenner: ON
2016-04-04 19:03:37 OWSWITCH Switch_Heizkeller Brenner: ON M-: OFF M+: OFF HWR: OFF EWT: ON F: OFF K_Pump: OFF 3W: OFF
2016-04-04 19:12:52 OWSWITCH Switch_Heizkeller Brenner: OFF
2016-04-04 19:12:52 OWSWITCH Switch_Heizkeller Brenner: OFF M-: OFF M+: OFF HWR: OFF EWT: ON F: OFF K_Pump: OFF 3W: OFF
2016-04-04 19:13:53 OWSWITCH Switch_Heizkeller Brenner: ON
2016-04-04 19:13:53 OWSWITCH Switch_Heizkeller HWR: ON

2016-04-04 19:13:53 OWSWITCH Switch_Heizkeller Brenner: ON M-: ON M+: ON HWR: ON EWT: OFF F: OFF K_Pump: OFF 3W: OFF

2016-04-04 19:14:53 OWSWITCH Switch_Heizkeller Brenner: OFF
2016-04-04 19:14:53 OWSWITCH Switch_Heizkeller Brenner: OFF M-: ON M+: ON HWR: ON EWT: OFF F: OFF K_Pump: OFF 3W: OFF
2016-04-04 19:15:53 OWSWITCH Switch_Heizkeller Brenner: ON
2016-04-04 19:15:53 OWSWITCH Switch_Heizkeller Brenner: ON M-: OFF M+: ON HWR: ON EWT: OFF F: OFF K_Pump: OFF 3W: OFF

In der mit Leerzeilen markierten Zeile ist die  gleichzeitige Aktivierung beider Mischers-Ports (M- und M+)  und der Tausch des Schaltzustandes von HWR und EWT erstaunlich, es gibt kein Event und mein eigener Code ist so geschrieben, dass er nur den einen oder den anderen Port M-/M+ (jeweils für 1 Sekunde) schaltet.

Bin einigermaßen ratlos. Gerne würde ich hilfreichere Infos ermitteln...

Herzliche Grüße

Christian

[Post zum Thema von heute morgen gelöscht weil leider noch unspezifischer]

[Prof. Dr. Peter Henning]

Hm. Müsste ich erst einmal im Detail die binären GPIO-Werte übersetzen. Vlt. die mal periodisch abfragen ?

LG

pah

[det.]

Hallo pah,
das wird sich um den Effekt handeln, den ich hier [size=78%]https://forum.fhem.de/index.php/topic,50412.msg431415.html#msg431415[/size] angefragt hatte. Probier bitte einfach mal aus - mehrmals hintereinander OFF eingeben und schaun was passiert.

[cwagner]

Moin, Pah & det,

das kann ich nun nach einer Nacht bestätigen und beliebig reproduzieren: Beispielsweise ist Kanal A off und E on.
Nun wird noch einmal ein set <device> output A off gesendet und nun geht A an und die nächsten drei. Dafür geht dann E aus. Ich habe jetzt 12 Stunden den GPIO-Zustand alle 30 Sekunden protokolliert - solange kein Port geschaltet wird, passiert nichts. Sobald aber ein Schaltzustand wiederholt wird, gibt es durcheinander:

Hier wurde ein Brenner OFF gesandt - ergebnis ist ein Brenner, M-, M+ und HWR ON. EWT wird OFF

Code Auswählen Erweitern

2016.04.05 08:54:59 3: TEST_Switch: OWSWITCH: Switch_Heizkeller.gpio => Brenner: OFF M-: OFF M+: OFF HWR: OFF EWT: ON F: OFF K_Pump: OFF 3W: OFF
2016.04.05 08:55:29 3: TEST_Switch: OWSWITCH: Switch_Heizkeller.gpio => Brenner: ON M-: ON M+: ON HWR: ON EWT: OFF F: OFF K_Pump: OFF 3W: OFF

Herzliche Grüße

Christian

[Prof. Dr. Peter Henning]

Dann scheint es noch irgendeine Inkonsistenz zu geben. Wenn man nämlich nur einzelne Outputs schaltet, holt sich die Kiste erst den Gesamtzustand, berechnet das neue gpio und schreibt das zurück.

Ich habe in das anliegende OWXSWITCH (Version 6.01beta) eine zusätzliche Debugausgabe eingebaut, wäre dankbar fürs Testen, da ich im Moment ziemlich unter Wasser bin wegen verschiedener Deadlines.

LG

pah

[cwagner]

Hallo pah,

das passte, war gerade etwas Zeit und so habe ich die Debug-Fassung gleich probiert: Das Ergebnis entspricht meiner Beschreibung - hier die Log-Infos (ich habe ledig Kanal A und E geschaltet und wenn "zuviele" Ports geschaltet wurden, habe ich mit GPIO 255 wieder zurückgesetzt auf alle AUS.

Code Auswählen Erweitern

2016.04.05 16:49:15 1: DEBUGGING OWXNG : After reading old gpio as 239, we are setting a new gpio as 237
2016.04.05 16:49:18 1: DEBUGGING OWXNG : After reading old gpio as 237, we are setting a new gpio as 245
2016.04.05 16:50:00 1: DEBUGGING OWXNG : After reading old gpio as 245, we are setting a new gpio as 247
2016.04.05 16:51:39 1: DEBUGGING OWXNG : After reading old gpio as 247, we are setting a new gpio as 248
2016.04.05 16:51:54 1: DEBUGGING OWXNG : After reading old gpio as 248, we are setting a new gpio as 249
2016.04.05 16:51:56 1: DEBUGGING OWXNG : After reading old gpio as 249, we are setting a new gpio as 250
2016.04.05 16:52:34 1: DEBUGGING OWXNG : After reading old gpio as 250, we are setting a new gpio as 251
2016.04.05 16:55:11 1: DEBUGGING OWXNG : After reading old gpio as 255, we are setting a new gpio as 254
2016.04.05 16:55:21 1: DEBUGGING OWXNG : After reading old gpio as 254, we are setting a new gpio as 255
2016.04.05 16:55:33 1: DEBUGGING OWXNG : After reading old gpio as 255, we are setting a new gpio as 256
2016.04.05 16:55:42 1: DEBUGGING OWXNG : After reading old gpio as 255, we are setting a new gpio as 256
2016.04.05 16:56:02 1: DEBUGGING OWXNG : After reading old gpio as 255, we are setting a new gpio as 256
2016.04.05 16:56:15 1: DEBUGGING OWXNG : After reading old gpio as 255, we are setting a new gpio as 239
2016.04.05 16:56:33 1: DEBUGGING OWXNG : After reading old gpio as 239, we are setting a new gpio as 240
2016.04.05 16:56:49 1: DEBUGGING OWXNG : After reading old gpio as 240, we are setting a new gpio as 241
2016.04.05 16:57:15 1: DEBUGGING OWXNG : After reading old gpio as 255, we are setting a new gpio as 239
2016.04.05 16:57:45 1: DEBUGGING OWXNG : After reading old gpio as 255, we are setting a new gpio as 256
2016.04.05 16:58:01 1: DEBUGGING OWXNG : After reading old gpio as 255, we are setting a new gpio as 239
2016.04.05 16:58:08 1: DEBUGGING OWXNG : After reading old gpio as 239, we are setting a new gpio as 239
2016.04.05 16:58:10 1: DEBUGGING OWXNG : After reading old gpio as 239, we are setting a new gpio as 240
2016.04.05 16:58:25 1: DEBUGGING OWXNG : After reading old gpio as 240, we are setting a new gpio as 241
2016.04.05 16:58:37 1: DEBUGGING OWXNG : After reading old gpio as 241, we are setting a new gpio as 242
2016.04.05 16:58:57 1: DEBUGGING OWXNG : After reading old gpio as 255, we are setting a new gpio as 239


Danke für Dein Engagement trotz der zeitlichen Beanspruchung

Christian

[det.]

Hallo pah,
auch gleich getestet mit einem 2406 - Szenario: alle beide Kanäle sind auf off und ich klicke 4x hintereinander output A off :

Code Auswählen Erweitern

2016.04.05 18:00:52 1: DEBUGGING OWXNG : After reading old gpio as 2, we are setting a new gpio as 3
2016.04.05 18:00:50 1: DEBUGGING OWXNG : After reading old gpio as 1, we are setting a new gpio as 2
2016.04.05 18:00:47 1: DEBUGGING OWXNG : After reading old gpio as 0, we are setting a new gpio as 1
2016.04.05 18:00:44 1: DEBUGGING OWXNG : After reading old gpio as 3, we are setting a new gpio as 4
bei mehfachem output A oder B on hintereinander passiert hingegen nichts unerwartetes :

Code Auswählen Erweitern

2016.04.05 18:05:19 1: DEBUGGING OWXNG : After reading old gpio as 0, we are setting a new gpio as 0
2016.04.05 18:05:17 1: DEBUGGING OWXNG : After reading old gpio as 0, we are setting a new gpio as 0
2016.04.05 18:05:15 1: DEBUGGING OWXNG : After reading old gpio as 0, we are setting a new gpio as 0
2016.04.05 18:05:12 1: DEBUGGING OWXNG : After reading old gpio as 2, we are setting a new gpio as 0
2016.04.05 18:05:10 1: DEBUGGING OWXNG : After reading old gpio as 2, we are setting a new gpio as 2
2016.04.05 18:05:08 1: DEBUGGING OWXNG : After reading old gpio as 2, we are setting a new gpio as 2
2016.04.05 18:05:04 1: DEBUGGING OWXNG : After reading old gpio as 2, we are setting a new gpio as 2
Da geht A bzw B auf on und bleibt so, egal wie oft man den Schaltbefehl wiederholt.

[UweH]

Ein "...output A on" bei einem DS2408 ergibt im Log:

Code Auswählen Erweitern

2016.04.05 19:30:08 1: DEBUGGING OWXNG : After reading old gpio as 255, we are setting a new gpio as 254

Danach "...output A off":

Code Auswählen Erweitern

2016.04.05 19:30:14 1: DEBUGGING OWXNG : After reading old gpio as 254, we are setting a new gpio as 255

Und noch ein "...output A off":

Code Auswählen Erweitern

2016.04.05 19:30:20 1: DEBUGGING OWXNG : After reading old gpio as 255, we are setting a new gpio as 256

und

Code Auswählen Erweitern

OWSWITCH: Could not set device DS2408, reason: Wide character in send at /usr/lib/i386-linux-gnu/perl/5.20/IO/Socket.pm line 284.

Gruß
Uwe

[Prof. Dr. Peter Henning]

OK, das war ein echter Fehler (man sollte seine Boole'sche Algebra beherrschen...).

Anbei die gefixte Version, getestet mit allen drei Schalterchips. Hier angehängt noch als Beta, wenn es keine weiteren Irrtümer gibt, wird das heute vormittag noch eingecheckt.

LG

pah

[Prof. Dr. Peter Henning]

Noch zwei Fixes:

OWMULTI - Dokumentation von "raw" repariert

OWCOUNT - Überschreiben des "model"-Attributs verhindert. Gibt jetzt nur einen Log-Eintrag, falls das model nicht stimmt.

Bitte um Tests durch die Betroffenen.

LG

pah

[UweH]

"Mein" Problem hat sich erledigt, vielen Dank

Gruß
Uwe

[det.]

Perfekt, Danke!

[cwagner]

Jep, auch bei meinem OWSWITCH zählt nun die Version 6.01Beta2 nur noch von 0 bis 255 und schaltet damit einwandfrei...

Danke, das war offenbar der Fehler...

[Prof. Dr. Peter Henning]

Neue Versionen sind als 6.01 eingecheckt

LG

pah

[papa]

Ich habe seit langer Zeit mal wieder meine Installation aktualisiert unbd habe nun massive Probleme mit den 1Wire Temperatursensoren. Es werden immer mal wieder negative Werte gemessen. Die 1Wire Anbindung erfolgt über Firmata. Ich habe insgesamt 3 Busse auf 3 Pins laufen. Leider kann ich nicht genau sagen, ob es nun an OWX_ASYNC oder FRM liegt. Komischerweise sind die falschen Werte auch unterschiedlich. Hier mal ein Logauszug:

Code Auswählen Erweitern


2016-04-07_05:10:56 temp_Aussen temperature: 7.125
2016-04-07_05:15:56 temp_Aussen temperature: 6.9375
2016-04-07_05:20:56 temp_Aussen temperature: -0.0625
2016-04-07_05:25:56 temp_Aussen temperature: 6.9375
2016-04-07_05:30:56 temp_Aussen temperature: 6.875
2016-04-07_05:35:56 temp_Aussen temperature: -121.1875
2016-04-07_05:40:57 temp_Aussen temperature: 6.8125
2016-04-07_05:45:57 temp_Aussen temperature: 6.75
2016-04-07_05:50:57 temp_Aussen temperature: -124.75
2016-04-07_05:55:57 temp_Aussen temperature: 6.8125
2016-04-07_06:00:57 temp_Aussen temperature: 6.8125
2016-04-07_06:05:57 temp_Aussen temperature: 6.6875
2016-04-07_06:10:57 temp_Aussen temperature: 6.8125
2016-04-07_06:15:57 temp_Aussen temperature: 6.75
2016-04-07_06:20:57 temp_Aussen temperature: 6.75
2016-04-07_06:25:57 temp_Aussen temperature: 6.75
2016-04-07_06:30:57 temp_Aussen temperature: 7
2016-04-07_06:35:57 temp_Aussen temperature: 6.875
2016-04-07_06:40:57 temp_Aussen temperature: 6.8125
2016-04-07_06:45:57 temp_Aussen temperature: 6.8125
2016-04-07_06:50:57 temp_Aussen temperature: 6.8125
2016-04-07_06:55:57 temp_Aussen temperature: -126.875
2016-04-07_07:00:57 temp_Aussen temperature: 6.6875


"tempConv" steht bei allen auf "onread". Das Problem tritt sowohl bei "buspowered" als auch bei Spannungsversorgung auf dem Bus auf.

Kann das unter Umständen mit den aktuellen Änderungen zusammen hängen ?

[Lorenz]

Hallo papa,

auch ich kann seit kurzem negative Ausreisser bei Temperatursensoren bestätigen. Allerdings setze ich dabei nicht Firmata ein. Bei mir sind alle Sensoren an einem 1-wire-Bus eines USB-Wandlers mit DS2480. Weiterhin sehe ich Fehlmessungen an DS2450, welche ich für die Luftfeuchte einsetze. Allerdings tritt das nur selten auf (ca. 1 Messwert pro Tag) und auch nicht bei allen Sensoren. Ich habe in letzter Zeit täglich Updates gemacht.

LG

[Prof. Dr. Peter Henning]

Man sieht an den teilweise richtigen Messungen, dass die Programme korrekt laufen. Damit können eigentlich auch keine falschen Werte gemessen werden, denn es erfolgt immer ein CRC-Check - und eine Fehlermeldung im Log, wenn dieser Check einen Irrtum anzeigt.

Diese Ausrutscher deuten auf ein Timing-Problem im Firmata-Interface bzw. bei OWX_ASYNC hin. Für beide bin ich nicht verantwortlich. Nochmal zur Roadmap:

Im Laufe von April/Mai werde ich eine neue Version von OWX einchecken (bisher nur als Alpha verfügbar), mit der OWX_ASYNC für die meisten Nutzer überflüssig wird. Daran richten sich die neuen Frontendmodule aus, ohne dass sie Probleme bei alten Installationen machen sollten.

LG

pah

[Lorenz]

Da bei mir OWX in einer eigenen fhem-Instanz läuft, habe ich bislang OWX und nicht OWX_ASYNC eingesetzt. Also ist OWX_ASYNC als Fehlerquelle ausgeschlossen. Ich habe auf dem Bus 11*DS18B20, 2*DS2450 und 1*DS2408 alles ohne parasitäre Buspower. Von diesen Busteilnehmer werden in 24 Stunden 4032 Werte abgefragt und davon waren jetzt am Tag ca. 5 falsch. Ist also nicht so dramatisch aber unschön, da dies in den letzten 2 Jahren nicht auffällig war. Ich habe jetzt mal testweise auf OWX_ASYNC umgestellt, um das Verhalten dabei zu beurteilen. Mal abwarten ...


LG

[Speed-Baron]

Ich habe nun auf die 6.01 upgedated und leider bleibt im Modul OWMULTI alles beim alten 

get <name> VDD, raw und temperature liefern Werte (wobei bei raw immer noch der zweite Wert 0 ist !?!)

get <name> V , liefert nach wie vor die Fehlermeldung: OWMULTI: Get with unknown argument V, choose one of VDD id interval present raw reading temperature version

get <name> version liefert nun 6.01

Ich hoffe das hilft weiter.

Schöne Grüße
Speedy

[Speed-Baron]

Noch etwas ist mir aufgefallen, nach dem Update von heute, sind folgende Zeilen aus dem Logfile wieder verschwunden:

Code Auswählen Erweitern

2016.04.07 16:02:05 3: Schalter_Relais_A: attrVal: Global symbol "$CMD" requires explicit package name (did you forget to declare "my $CMD"?) at (eval 22) line 1, <$fh> line 11.

2016.04.07 16:02:05 3: Schalter_Relais_A: attrVal: Global symbol "$LASTCMD" requires explicit package name (did you forget to declare "my $LASTCMD"?) at (eval 23) line 1, <$fh> line 13.

Ich vermute, das hängt mit dem Update von OWSWITCH zusammen - nur ein Feedback der Vollständigkeit halber 

Schöne Grüße
Speedy

[Speed-Baron]

Oooooh sorry, habe gerade in der Commandref gesehen, dass pah dort nachgebessert hat.

get <name> raw liefert nun die Werte V und W - get <name> V gibt es nicht mehr!

Somit ist mein Post von vorhin natürlich hinfällig.

Tatsache ist aber, dass ich zwischen PIN 2 und 3 des DS2438 eine Spannung von 204 mV messe?!?

Schöne Grüße und sorry für meine vorschnelle Antwort
Speedy

[Prof. Dr. Peter Henning]

Ich vermute, das hängt mit dem Update von OWSWITCH zusammen - nur ein Feedback der Vollständigkeit halber

Eher unwahrscheinlich, da in dem Modul die Variablen $CMD und $LASTCMD nicht auftreten.

Tatsache ist aber, dass ich zwischen PIN 2 und 3 des DS2438 eine Spannung von 204 mV messe?!?

Ja, und ? Was sagt denn das reading dazu ?

LG

pah

[Speed-Baron]

Hallo pah,

das reading liefert folgendes Ergebniss.
Bei allen drei DS2438, die ich besitze gleich.

Schöne Grüße
Speedy

[martinbaumert]

Hallo,

am 6.4. habe ich einen Update bei der FHEM gefahren.

Gestern ist mir aufgefallen, dass die beiden 8-Kanal Board´s (DS2408) nicht mehr schalten - alle Relais sind "ON".

Alle Relais werden auch, wenn ich die Spannung komplett vom System nehme, nach kurzer Zeit wieder, auf "ON" gesetzt (gemeinsam). Sie lassen sich auch durch keinen Befehl aus FHEM ausschalten.

Über OWServer (Port 2121) kann ich EIN und AUS schalten.

Im Logfile finde ich folgende Meldungen beim "Starten"

2016.04.09 17:02:56 0: Featurelevel: 5.7
2016.04.09 17:02:56 0: Server started with 256 defined entities (fhem.pl:11191/2016-04-05 perl:5.014002 os:linux user:fhem pid:5995)
2016.04.09 17:02:58 3: CUL_HM set LichtOG statusRequest
2016.04.09 17:02:58 3: PID20 PIDMischer1: Calc.709 <set D_StellPID  100>
2016.04.09 17:02:58 3: PID20 PIDMischer2: Calc.709 <set D_StellMPID  100>
2016.04.09 17:03:00 1: PERL WARNING: Argument "Brenner_Freigabe" isn't numeric in right bitshift (>>) at ./FHEM/21_OWSWITCH.pm line 967.
2016.04.09 17:03:01 1: PERL WARNING: Argument "Mischer1_UP" isn't numeric in right bitshift (>>) at ./FHEM/21_OWSWITCH.pm line 967.
2016.04.09 17:03:01 1: PERL WARNING: Argument "Mischer1_Auf" isn't numeric in right bitshift (>>) at ./FHEM/21_OWSWITCH.pm line 967.
2016.04.09 17:03:02 1: PERL WARNING: Argument "Mischer1_Zu" isn't numeric in right bitshift (>>) at ./FHEM/21_OWSWITCH.pm line 967.
2016.04.09 17:03:02 1: PERL WARNING: Argument "Mischer2_UP" isn't numeric in right bitshift (>>) at ./FHEM/21_OWSWITCH.pm line 967.
2016.04.09 17:03:02 1: PERL WARNING: Argument "Mischer2_Auf" isn't numeric in right bitshift (>>) at ./FHEM/21_OWSWITCH.pm line 967.
2016.04.09 17:03:03 1: PERL WARNING: Argument "Mischer2_Zu" isn't numeric in right bitshift (>>) at ./FHEM/21_OWSWITCH.pm line 967.

Bin jetzt bei Version: 6.01beta2

Schalte ich alle Relais über den OWServer "Aus". Sind sie auch aus (Kontrolle: LED ist aus). Sobald ein Relais eingeschaltet wird, schalten alle Relais ein. Aus geht nur über OWServer.

Weiß leider keinen Rat mehr. Auch ein Rücksetzten der Versionen hat bei mir nichts gebracht.

Danke, für jede Hilfe.

Gruß
Martin

[cwagner]

Dein Fehler wird vermutlich durch einen inzwischen vom Modulautor behobenen Fehler verursacht, den ein anderer Benutzer und ich beschrieben hatten. Mit Version 6.01 von OWSwitch, wie es im aktuellen Update verteilt wird, kommen zumindest bei bei mir keine Fehlerschaltungen mehr vor. Ich benutze auch einen 8fach-Switch (von Denkovi).

Grüße

Christian

[Prof. Dr. Peter Henning]

@ martinbaumert:

Erstens gehört es zu einer Fehlermeldung, dass man seine Konfiuration wenigstens beschreibt. Im vorliegenden Post kann man sich mühsam zusammenreimen, dass es eine Kombination aus OWSWITCH und OWServer ist.

Zweitens ist die Version 6.01beta2 nicht per Update verteilt worden - sondern nur hier zum Download für Experten.

Drittens ist der Codebestandteil, der mit OWServer interagiert, in der gegenwärtigen Entwicklung gar nicht angefasst worden.

Sorry also: Mit dem Post kann ich gar nichts anfangen.

LG

pah

[martinbaumert]

Entschuldigung für die unzureichenden Angaben. Ich weis leider nicht was ggf. wichtig ist.

Ich habe auf einer Raspi B die FHEM 5.7 am laufen. Über onewire (USB - Denkovi) erfasse ich die Temperaturen in meinen Heizsystem und steuere über unterschiedliche Module die Ausgänge auf den beiden Relaisboard (8-fach von Denkovi / DS2408) an.

Die Ausgänge habe ich entsprechend benannt z.B. "Mischer2_UP" oder "Mischer2_Zu" u.s.w.

Hier ein Auszug aus meiner fhem.cfg wie ein Relaisboard angelegt ist.

define DS2408_6D4816000000 OWDevice 29.6D4816000000 1800
attr DS2408_6D4816000000 IODev myOWS
attr DS2408_6D4816000000 model DS2408
attr DS2408_6D4816000000 room OWDevice
#
define RB2HA OWSWITCH DS2408 6C610C000000
attr RB2HA AName Mischer2_Zu
attr RB2HA BName Mischer2_Auf
attr RB2HA CName Mischer2_UP
attr RB2HA DName HZMieterEG
attr RB2HA EName HZMieterOG
attr RB2HA HName HZVDach
attr RB2HA IODev myOWS
attr RB2HA model DS2408
attr RB2HA room HZ-Mieter,OWDevice
attr RB2HA verbose 5


Habe gerade noch einmal eine Update gefahren. Keine Änderung - alle Relais sind an.

Danke
Martin

[Prof. Dr. Peter Henning]

@martinbaumert:
Bitte mal die angehängte Version von OWSWITCH ausprobieren.

LG

pah

[martinbaumert]

Guten Morgen und Danke.

Nach den Starten gibt es keine Fehlermeldungen mehr in der Logdatei. Es wir auch nur noch das entsprchend Relais angesteuert.

Gruß
Martin

[Speed-Baron]

Hallo zusammen,

leider ist mein Post jetzt untergegangen. 
Mag da vielleicht auch noch mal jemand drüberschauen.

Danke und wäre echt cool.

Schöne Grüße
Speedy

Hallo pah,

das reading liefert folgendes Ergebniss.
Bei allen drei DS2438, die ich besitze gleich.

Schöne Grüße
Speedy

[sdz35]

Nach dem Update habe ich auch einzelnen negativen Temperaturwerte.(DS2480   OWX_ASYNC)
Ferner werden jetzt für definierte aber nicht angeschlossene Sensoren plötzlich unsinnige  Werte  anstatt nur defined angezeigt .

LG

Johannes

[Prof. Dr. Peter Henning]

@SpeedBaron: Ich soll "mal drüberschauen" ? Witzige Idee.

@sdz35: Nicht angeschlossene Sensoren liefern Werte ? Noch witziger.

rofl

pah

[cwagner]

Hallo pah,
mir ist aufgefallen dass bei OWMulti als Attribut stateformat keine Wirkung hat. Meine Konfiguration:

Code Auswählen Erweitern

   VFunction  (157.233 * V / VDD - 23.2808) / (1.0546 - 0.00216 * T)
   VName      humidity|humidity
   VUnit      Prozent|%
   event-on-change-reading state,temperature,humidity
   model      DS2438
   stateFormat {"T: ".round(ReadingsVal($name,"temperature",0),1). " H: ".round(ReadingsVal($name,"humidity",0),1)}
   userReadings temperature {round(ReadingsVal($name,"temperature",0),1)}


Das ergibt dann eben diese Readings, beim State hatte ich bisher mit meinem Attribt die "klassische" Darstellung T: XX.X  H:XX.X erhalten:

Code Auswählen Erweitern

2016-04-10 16:28:07   VDD             5.03
2016-04-10 16:28:07   humidity        70.13
2016-04-10 16:28:07   sense           0
2016-04-10 16:28:07   state           humidity: 70.13 Prozent|% (T:  18.7 °C s:  0.00 V)
2016-04-10 16:28:07   temperature     18.7

Herzliche Grüße

Christian

[sdz35]

Ja konstant -1,25  (10er Familie) bzw -0.0625 (28er).

[Speed-Baron]

Hallo zusammen,

mit drüber schauen meinte ich, über meinen Post.

Gerne erläuter ich aber auch noch mal, was nicht funktioniert.
Ich messe an drei Sensoren DS2438 zwischen PIN 2 und PIN 3 (das entspricht V_sense+ und V_sense- bei Tageslicht ca. 200 mV. (die Werte sind bei allen drei Sensoren etwas unterschiedlich, deshalb ca., aber alle im Bereich um die 200 mV)
Das Reading von OWMULTI liefert 0,00 V

Angehängt nochmal der Screenshot, da pah das vorgestern angefragt hatte.

Aus meiner Sicht sollte OWMULTI den mit einem Multimeter gemessenen Spannungswert auch anzeigen - tut es aber nicht.
Die anderen Werte werden angezeigt, wie man dem Screenshot entnehmen kann.
Ich gehe davon aus, dass meine DS2438 funktionieren.

Aus diesem Grund hatte ich geschrieben, ob jemand nochmals bitte "drüber schauen" kann.
Sollten noch Daten oder weitere Informationen benötigt werden, werde ich mich bemühen, diese zu liefern.

Schöne Grüße
Speedy

[Prof. Dr. Peter Henning]

@cwagner: Nur abgesehen davon, dass der Mechanismus von stateFormat komplett außerhalb von OWMULTI liegt, kann ich das auch nicht bestätigen. Wie man an diesem Bild hier sieht, (http://owmulti.png) funktioniert das Bestens.

LG

pah

[sdz35]

Nachdem ich OWTHERM aus dem Backup zurückgespielt habe werden keine Werte mehr für nicht vorhandene Sensoren angezeigt.

[cwagner]

Hallo pah,

hier habe ich nicht sauber zwischen dem Internal STATE und das Reading state unterschieden.

Grüße
Christian

[Prof. Dr. Peter Henning]

@cwagner: "state" wird durch stateFormat auch normalerweise nicht verändert, sondern nur "STATE". Siehe CommandRef.

@sdz35. Prima. Einfach OWTHERM vom Update ausschließen, dann kann alles so bleiben.

LG

pah

[papa]

Hallo pah

@sdz35. Prima. Einfach OWTHERM vom Update ausschließen, dann kann alles so bleiben.

das ist ja nun auch keine Lösung. Ich habe gestern auch mal das alte OWTHERM zurück gespielt und habe seitdem keine negativen Werte mehr. Werde heute Abend nochmal die genaue Version raussuchen. Es scheint hier doch einen Zusammenhang zu geben.

papa

[Prof. Dr. Peter Henning]

das ist ja nun auch keine Lösung

Doch, ist es.

Wenn die eher verschachtelte Timing-Struktur von OWX_ASYNC mit den neuen Frontendmodulen manchmal (und eben nur manchmal, Grund unklar)  nicht zu Recht kommt, muss man bei den alten Versionen der Frontendmodule bleiben, Punkt. Das bedeutet bis auf eine Stelle bei OWMULTI keine Einschränkung der Funktionalität, somit ist auch kein Grund zum Update oder gar für Beschwerden gegeben.

Jeder kann gerne in den Frontendmodulen die speziellen Unterprogramme für OWX_ASYNC anpassen - aber die Kernroutinen werden nicht verändert.

LG

pah

P.S.: Ich betreibe an die hundert verschiedene Sensoren und Aktoren an 6 verschiedenen 1-Wire Bussystemen, und solche Fehler treten bei mir nicht auf.   

[papa]

Ich hatte inzwischen auch schon auf OWX zurück gestellt und trotzdem negative Werte. Erst der Austausch von OWTHERM hat geholfen.

Alte Version ist:

# $Id: 21_OWTHERM.pm 7181 2014-12-10 05:13:48Z pahenning $

[Prof. Dr. Peter Henning]

Das glaube ich nicht, denn solche Messwerte kommen durch OWX wegen des ordnungsgemäßen CRC check  _eben nicht_ durch. Wahrscheinlich also doch nicht auf OWX umgestellt...

Ist aber letzlich egal - denn an der Funktionalität hat sich nichts geändert. Also: Bei den alten Modulen bleiben, exclude from update.

LG

pah

[Bartimaus]

Nabend,

wird das Reading "present" in den Modulen OWTHERM oder OWMULTI via OWX nicht mehr aktualisiert ?