Serving a "remote" building

Thanks for the work to do this testing! That's good news, for edge cases where it might be useful. Have you tried it with varying latencies between the server and client? I would be interested to see if it stays stable with latency that is >1ms (non-LAN) and see where it falls apart. Serial-over-network is finicky in my experience.

It still requires a completely separate Mac and Indigo license, and running two Indigo servers instead of one "big" server. So it's useful for unusual situations where you don't want to put a Mac out in a remote building but still means a lot of complexity at the head-end of the network. Or am I mis-understanding the result?

JT

...good news, for edge cases where it might be useful. Have you tried it with varying latencies between the server and client? I would be interested to see if it stays stable with latency that is >1ms (non-LAN) and see where it falls apart. Serial-over-network is finicky in my experience.

It still requires a completely separate Mac and Indigo license, and running two Indigo servers instead of one "big" server. So it's useful for unusual situations where you don't want to put a Mac out in a remote building but still means a lot of complexity at the head-end of the network. Or am I mis-understanding the result?...

I think, perhaps, you are mis-understanding. I have not created a second instance of Indigo, or a secondary controller. All I have done is move the Z-Stick away from the Indigo server and connect Indigo to the Z-Stick over an IP network (Ethernet or Wi-Fi).

To do this I used a low cost mini travel router as a Z-Stick server and then connected to that using the existing Indigo Interfaces -> Z-Wave -> Configure settings pane.

As for latency.... Ping times from Indigo to the Z-Stick server are tightly clustered around 0.5 ms. Of course, this is to be expected since everything is on the same LAN. I have not tried testing by adding additional latency

Since this discussion has shifted from the original topic, which was more about adding an additional Z=Wave controller, I have started a separate topic to focus on removing the single Z-Wave controller. Click here for the new topic.

...How or what does Indigo use/do to show a list of available Z-Wave controllers?...

While waiting for an authoritative reply, I may have an answer to your question. I don't think Indigo actually creates a list of available controllers. Rather, I think when Local (physical) is selected the Connection Type: and the user clicks on the Serial Port: drop down, Indigo populates that list with any devices it finds in /dev that match a presumed patters. Like cu.SLAB_USB*|cu.usbmodem*|etc.

So, unless the actual USB device is mounted in /dev, it won't appear in Indigo.

Or, maybe there is a clue inthis thread.

[jay (support)]

You can see serial ports in the /dev/ directory. For it to show up there, some driver must add it. Insteon devices use the FTDI driver, the Z-Stick Series 2 uses the SILabs driver, the Gen5 identifies itself as a modem so Apple's built-in modem driver grabs it.

If the port shows up in the /dev/ directory but not in Indigo then that's one problem. If it doesn't appear in the /dev/ directory at all then it's a driver issue.

[jay (support)]

What do you see when you do:

Code: Select all

ls -la /dev/tty.*

I'm not positive that's how we're filtering it, but it's close.

[jay (support)]

We're doing a POSIX system call to give us available serial ports, then filtering out bluetooth and any iOS related ones.

I think tty.* is a close approximation to what POSIX is giving us.

...I think the DS-510 is not passing the correct info to macOS for it to load the appropriate driver...
...So it does appear that the DS-510 has an issue with this device. Still waiting to hear back from Silex.

Perhaps you missed my previous posts in which...

The issues I found were not with the USB server or client, they were with the MacOS built-in drivers. I wouldn't be surprised if your Silex box works in general, but not with the Z-Stick.

I posted on the VirtualHere support forum and received this reply

Yes its a pain, some devices wont work via virtualhere. They were all working nicely up to osx 10.10 , in 10.11 apple entirely removed support for USB Host drivers from 3rd parties. Since there have been a lot of complaints from different companies apple has gradually put support back into osx again for 3rd party drivers. It gets better as time goes on. 10.12 when they first put some support for usb drivers back in they were pretty buggy. Now most devices work again via virtualhere. There is no release notes from apple that say this because its confidential

Your experience is exactly the same as I had with VirtualHere and almost certainly can be traced to Apple's modem driver: AppleUSBCDC.kext

...Of course one big advantage of using that Homeseer box is you might be able to perform OTA updates to devices directly from it all while Indigo can still communicate with the Homeseer to control the Z-wave devices. No more unplugging the Z-Wave controller and plugging it into a Windows machine to update firmware.....

I just installed Z-Way (from Z-Wave.me) on an R-Pi. It is really a home automation product, but it does have controller management features like backup/restore and firmware updates. However, I am not sure if you could simultaneously share (via ser2net) the controller with Indigo while it was being updated. OTOH, I am not sure the HomeSeer Z-NET can do that either.

Back on topic here, having two controllers...

I backed up my Aeotec Z-Stick and restored the backup onto a Z-Wave.me stick. I then mounted the Z-Wave.me device in a Raspberry-Pi and shared it to a 2nd instance of Indigo (my development machine). I was then able to add the same devices on the 2nd instance of Indigo that I had on my main Indigo server, AND, they worked. This is not the same thing as serving a separate location, it is really more or moving from one instance of Indigo to another. But, it is none-the-less a bit of progress.

...Of course one big advantage of using that Homeseer box is you might be able to perform OTA updates to devices directly from it all while Indigo can still communicate with the Homeseer to control the Z-wave devices. No more unplugging the Z-Wave controller and plugging it into a Windows machine to update firmware.....

I just installed Z-Way (from Z-Wave.me) on an R-Pi. It is really a home automation product, but it does have controller management features like backup/restore and firmware updates. However, I am not sure if you could simultaneously share (via ser2net) the controller with Indigo while it was being updated. OTOH, I am not sure the HomeSeer Z-NET can do that either.

I've been playing with the Z-Way software a bit more and I am now sure you cannot share the controller and also do maintenance tasks on it at the same time. It makes sense. If the local (I.e. on the R-Pi) software has control of the device, the sharing software cannot access it, and vice-versa. I am not sure if HomeSeer uses Z-Way behind the scenes, but I have to imagine they will suffer from the same limitation.

OTOH, I also did a backup using the Z-Way software. Since the Z-Way interface is via a browser the backup can be done from my Mac and, the best part, the backup is saved directly to my Mac. Switching between Z-Way and sharing on the R-Pi takes three commands. But, they could be combined into one command. Though at the moment though, I have to login to the R-Pi to do the switch, though I imaging it would be fairly easy to do that through Indigo.

Even the DS-510 wouldn't be able to let two devices use the serial port at the same time. However, you could just disconnect it virtually from Indigo, do what you need under a Windows system(backup, restore, OTA, etc.) and then switch it back all while never leaving the comfort of a chair.

You may have missed what I reported. Using my FrankenSeer (R-Pi + Z-Wave.me) I can not only backup and update my Z-Wave controller from the comfort of my chair, I can do it all from MacOS (No VM required). I can even do the server virtual disconnect/reconnect from an Indigo Action.

However, using the Z-Way API, there is much more than can be done. See my next post.

Back on topic...

I have started looking into the Z-Way API and it looks like it supports control of devices remotely.. That is to say, you could use this much like a remote Vera, but with direct control and for the price of a Z-Stick + a Raspberry-Pi. I am just starting to dig into the API, and hopefully I will have more to report soon. But, it looks like an Indigo plugin, with Indigo device instances for all the remote Z-Wave devices, is a real possibility. On the downside, this would still be separate from Indigo and require learning a new system and a certain amount of extra work to maintain.

BTW, If anyone else wants to help with the development of this please let me know.

We're doing a POSIX system call to give us available serial ports, then filtering out bluetooth and any iOS related ones.
I think tty.* is a close approximation to what POSIX is giving us.

Well, this is interesting. I was able to create a device in /dev by turning off SIP, starting scout, which created /dev/ttys002 and then doing

sudo mv /dev/ttys002 /dev/ cu.usbmodem14101

Next, I plugged a UZB1 into the Mac, and it was automatically assigned /dev/cu.usbmodem14201
Then I did

Code: Select all

$ ls -l /dev/cu*
crw-rw-rw-  1 root  wheel   18,   3 Feb  9 14:17 /dev/cu.Bluetooth-Incoming-Port
crw-rw-rw-  1 root  wheel   18,   1 Feb  9 14:17 /dev/cu.RichardsMacBook-Bluetoo
crw-rw-rw-  1 root  wheel   18,   5 Feb  9 14:17 /dev/cu.RicksiPhoneX-WirelessiA
crw-rw-rw-  2 root  wheel   16,   2 Feb  9 17:48 /dev/cu.usbmodem14101
crw-rw-rw-  1 root  wheel   18,   9 Feb  9 17:42 /dev/cu.usbmodem14201

Seems Ok. But, when I try to configure the Z-Wave controller what I see is

Screen Shot 2019-02-09 at 17.52.58 .png (156.2 KiB) Viewed 2311 times

So, it would appear whatever call you are using is not looking at /dev Also odd it showed a Bluetooth device?

EDIT: With SIP off, I was able to get socat to create ttys003 and symlink it to cu.usbmodem14101
lrwxr-xr-x 1 root wheel 0 Feb 9 18:44 /dev/cu.usbmodem14101 -> /dev/ttys003

EDIT 2: And then magically it stopped working until I disabled SIP again.

But, Indigo still does not recognize this.