Z-Wave Donge über Netzwerk nutzen?

[stenny]

Hallo

Gibt es eine möglichkeit wie ich einen Z-Wave Dongle über das Netzwerk ansprechen kann?
Ich meine so ähnlich wie mit dem HM-USB-Dongel und hmland...


stenny

[justme1968]

schau dir mal ser2net an. damit sollte es gehen.

gruß
  andre

[stenny73]

Habe bereits ein wenig mit usb over ip getestet. Jedoch lief dieses nicht so wirklich wie erhofft.
Wenn der Usbekistan Server mal ausfiel und neu gestartet ist baut der Client nicht zuverlässig
Wieder auf. Daher hatte ich auf etwas ähnliches wie den hmland gehöfft.....

[rudolfkoenig]

Ich gehe davon aus, dass der "Client zuverlaessig auf" ist, wenn man lange genug (2h+) wartet. Diesen Intervall kann man mit einem "define zPing at +*00:01 get ZWDongle version" verkuerzen. CUL_HM macht sowas automatisch alle 30 Sekunden, deswegen faellt der Ausfall bei hmland vorher auf.

[mattwire]

/etc/ser2net.conf auf mein server "mercurypi":

Code Auswählen Erweitern

3001:raw:0:/dev/zwave:115200 8DATABITS NONE 1STOPBIT

Fhem... auf mein fhem server:

Code Auswählen Erweitern

define ZWDongle_0 ZWDongle mercurypi:3001

Das bringt ein Fehler und crash:
"Can't call method "can_dtrdsr" on an undefined value at FHEM/DevIo.pm line 370."

Fixiert mit diesem Patch (aber was ist die Konsequenz fuer SerialGerate?):

Code Auswählen Erweitern

Index: 00_ZWDongle.pm
===================================================================
--- 00_ZWDongle.pm (revision 8829)
+++ 00_ZWDongle.pm (working copy)
@@ -465,7 +465,7 @@
   my $name = $hash->{NAME};
   $serInit = 1;

-  DevIo_SetHwHandshake($hash) if($hash->{FD});
+#  DevIo_SetHwHandshake($hash) if($hash->{FD});
   $hash->{PARTIAL} = "";
   
   ZWDongle_Clear($hash);

[rudolfkoenig]

Danke fuer die Info. Habe die Zeile modifiziert, und so

Code Auswählen Erweitern

  DevIo_SetHwHandshake($hash) if($hash->{USBDev});
eingecheckt, das sollte beie Faelle korrekt abdecken.

[mattwire]

Mit der Dongle uber network hatte ich viele Probleme mit status, disconnect, und 100% CPU.

Die 100% CPU war im ZWDongle_Clear "for loop" funktion:

Code Auswählen Erweitern

-    last if($err && $err =~ m/^Timeout/);
+    last if($err);

Andere Probleme sind mit readings->state="disconnected" aber INTERNAL->STATE="Initialized":
Bitte sehen Sie die Patch im Anhang.

[rudolfkoenig]

Im Diff sind zu viele Aenderungen, die ich nicht nachvollziehen kann.
Das Problem bleibt auf meiner TODO Liste, ich will es selbst nachstellen.

[mattwire]

Danke Rudolf,

To help you.  The two main problems are (in Meine Meinung):
1. Infinite loop in ZWDongle_Clear when device is disconnected but valid FD.
2. Many situations when reading->state="disconnected" and INTERNAL->STATE="Initialized".  The code is only looking at INTERNAL->STATE and does not understand that the dongle is disconnected.

I'm sure my diff is not perfect.  But hopefully it will help you to find the best solution.

Matthew

[rudolfkoenig]

I could not detect any serious issues, but i fixed two small ones:
- skip resends due to missing ACK if the Dongle is disconnected
- make reopen work even if the DevIO set reconnect-timeout-for-network-devices of 1 minute is not reached

How I tested:

% socat tcp4-listen:9999,reuseaddr file:/dev/cu.usbmodemfa141,nonblock,echo=0,raw
define D ZWDongle localhost:9999

What have I tested:
- open: ok
- terminate socat, immediate disconnect reported
- get Dongle version: fhem reports No FD (dummy device?)
- start socat, after one minute: automatic reopen happens, get Dongle version is working again
- stop/start socat, set Dongle reopen, get Dongle version: works.

If you still have some issues, then please describe exactly, how to reproduce them.

[mattwire]

Here is my configuration:
- ZWDongle on remote host "mercurypi" exported by ser2net.conf:

Code Auswählen Erweitern

3001:raw:0:/dev/zwave:115200 8DATABITS NONE 1STOPBIT

- socat on fhem host "marvin":

Code Auswählen Erweitern

socat pty,link=/dev/zwave,b115200,raw,echo=0,wait-slave TCP:mercurypi:3001

With the latest from SVN I still have problems with 100% CPU:
1. Everything running ok.
2. Reboot host "mercurypi".  Following log is produced:

Code Auswählen Erweitern


2015.07.12 09:58:07 1: mercurypi:3002 disconnected, waiting to reappear (CUL_0)
2015.07.12 09:58:07 1: /dev/zwave disconnected, waiting to reappear (ZWDongle_0)
2015.07.12 09:58:41 3: Setting ZWDongle_0 serial parameters to 115200,8,N,1
2015.07.12 09:58:41 1: /dev/zwave reappeared (ZWDongle_0)
2015.07.12 09:58:41 4: ZWDongle_ReadAnswer arg:Clear regexp:wontmatch
2015.07.12 09:58:42 1: /dev/zwave disconnected, waiting to reappear (ZWDongle_0)
2015.07.12 09:58:43 1: ZWDongle_ReadAnswer: no data read

3. perl process goes to 100% cpu:

Code Auswählen Erweitern

24332 fhem      20   0 28340  25m 2004 R 100.0  1.3   6:56.28 perl
4. Restart fhem.  Everything working

For me this happens every time the above steps are followed.

[rudolfkoenig]

Could you please try my version, i.e. socat on the host with the Dongle (mercurypi), and accessing it with the mercurypi:3001 syntax in the ZWDongle definition? I dont want to debug a potentially buggy ser2net to socat communication.

[mattwire]

Hi, I've done some more tests and think there are still issues.

Scenario1: socat
mercurypi: socat tcp4-listen:3001,reuseaddr file:/dev/zwave,nonblock,echo=0,raw
marvin (fhem): mercurypi:3001

1. Both running and connected.
2. reboot mercurypi.  Disconnect and reconnect: Correct
3. Issue fhem "shutdown restart" on marvin.  Fhem shows disconnected with logfile (it's trying to open twice?):

Code Auswählen Erweitern

2015.07.13 23:30:34 3: Opening ZWDongle_0 device mercurypi:3001
2015.07.13 23:30:34 3: ZWDongle_0 device opened
2015.07.13 23:30:35 3: Opening ZWDongle_0 device mercurypi:3001
2015.07.13 23:30:36 3: Can't connect to mercurypi:3001: Connection refused

Scenario2: ser2net
mercurypi: ser2net: 3001:raw:0:/dev/zwave:115200 8DATABITS NONE 1STOPBIT
marvin (fhem): mercurypi:3001

Impossible to run. Fhem gets stuck in 100% CPU after the following log events:

Code Auswählen Erweitern

2015.07.13 23:41:12 3: Opening ZWDongle_0 device mercurypi:3001
2015.07.13 23:41:12 3: ZWDongle_0 device opened
2015.07.13 23:41:14 3: Opening ZWDongle_0 device mercurypi:3001
2015.07.13 23:41:14 3: ZWDongle_0 device opened
2015.07.13 23:41:14 1: ZWDongle_0: SOF missing (got 50 instead of 01)
2015.07.13 23:41:14 1: mercurypi:3001 disconnected, waiting to reappear (ZWDongle_0)
2015.07.13 23:41:14 1: ZWDongle_ReadAnswer: no data read

I added a log statement and the cause of 100% CPU is 00_ZWDongle.pm is stuck in ZWDongle_Clear for loop.

[rudolfkoenig]

socat needs the fork option, if you want to use it with a "shutdown restart" or equivalent. Just tested, no problems for a shutdown restart:

Code Auswählen Erweitern

socat tcp4-listen:3001,reuseaddr,fork file:/dev/cu.usbmodemfa141,nonblock,echo=0,raw

[rudolfkoenig]

I fixed a bug in ZWDongle_Clear which resulted in an endless loop (100%CPU) when the USB-device, connected through socat is unplugged. As far as I see, you have to execute a "set dongle reopen" in order to be able to communicate with the device again after replugging it, as the socat network connection remains open.
As an alternative you can restart socat.

[mattwire]

Danke Sehr!  Jetzt mit ein Kleine Aenderung mehr wird alles funktioniert:

ZWDongle_DoInit:

Code Auswählen Erweitern


-  $hash->{STATE} = "Initialized";
+  readingsSingleUpdate($hash, "state", "Initialized", 1);


(Diese Ziel habe ich schon im 00_CUL.pm gesehen)

[rudolfkoenig]

Habs eingecheckt.

[adb76]

Habs eingecheckt.

Kann es sein, dass diese Änderung durch die Sourceforge Probleme verloren gegangen ist? Aktuell ist dort die Version $Id: 00_ZWDongle.pm 8964 2015-07-14 12:21:26Z rudolfkoenig $ m. M. ohne diese Änderung in ZWDongle_DoInit.

Gruss,

André

[rudolfkoenig]

Ja, kann sein, habs jetzt hoffentlich eingecheckt.

[mattwire]

Hi Rudolf,  I have still been having some problems on restart of fhem.

When fhem restarts the ZWDongle state = Initialized but any commands returns "No FD".  So I detect this state and mark the dongle disconnected.  A get command then attempts a reconnect if disconnected.

This patch fixes it for me: https://github.com/mattwire/fhem-mirror/commit/a2c452ae1fb3022fa7f8de9ad686209172683fb3

[rudolfkoenig]

This patch is too crude for me. I tested the network connection with

socat OPEN:/dev/XXX TCP-LISTEN:12345,reuseaddr,fork

and I could detect no problems, neither by "shutdown restart", nor by aborting and restarting the socat process.

[mattwire]

Well I am using ser2net on a remote host.  The remote host is not restarting.

It is only happening when I restart fhem, fhem gets in a state where it thinks it has connected but returns "No FD" and is clearly not connected.  To be robust, I think that on detection of "No FD" the state should be set to disconnected at least?  Since that is the actually detected state.

[rudolfkoenig]

You are right, but AFAIK the "No FD" case can only happen, if DevIo_CloseDev is called, wich sets the state to disconnected, which in turn triggers the check of the peer every 5 seconds. It surely worked in my case.
Can you describe a test scenario on how to reproduce your case?

[mattwire]

You are right, but AFAIK the "No FD" case can only happen, if DevIo_CloseDev is called

Config: http://forum.fhem.de/index.php/topic,38315.msg307331.html#msg307331

This is happening for me everytime I restart fhem.  Maybe it is some kind of race condition at startup?  By the way I think this problem only appeared after the sourceforge crash.

To improve code reliability shouldn't the "No FD" be handled even if it should never happen?

[mattwire]

Hallo,

After reading the advice on the wiki page: http://www.fhemwiki.de/wiki/DevelopmentIntroduction#STATE I have changed all hash->{STATE} to readingsVal/readings..Update as per the attached patch.  This simple change seems to have completely solved my network disconnecting/reconnecting issues and has had no reconnect problems for the last two weeks.

If you are happy please commit this change.  (I think the reason was the mixture of different ways to access/change STATE during initialisation was causing the module/fhem to become confused (given the much longer round-trips to communicate over the network).

Thankyou,
Matthew

[rudolfkoenig]

Thanks, i've made some quick tests and checked it in.