I appear to have learned nothing from the first time this happened!
For good measure, I restarted my production server and then the USB CIM on /dev/ttyUSB0 was instantly discovered by the UPB integration.
Now to see if the USB CIM experiences any of the stability problems mentioned by webmtn in this post. The difference is it’s being used with Linux, instead of Windows, so maybe the lockup problems he observed won’t manifest themselves in this environment. I should know more after a few days of operation.
FWIW, I had installed Putty and Minicom and both were able to connect to the USB CIM via /dev/ttyUSB0. It got me thinking about how all three programs, Putty, Minicom, and ser2net, were able to use the port but the UPB integration could not. That gave me a sense of déjà vu …
I’m also glad that this “problem that was never an actual problem” is now resolved. Now to confirm the USB CIM works as reliably (or not) as the serial model.
Putty, Minicom, and ser2net were all outside of the HA container IIRC. Inside the container there seems to be a need for the reboot. Might be something to raise with the supervisor team since it has caused grief a couple of times – and that’s just here. Even if there were some type of message alert.
It seems that the appearance of a new port is not relayed to Home Assistant in “real time”. The container has to be restarted in order for it to access the new port.
I’m using Home Assistant Supervised on Ubuntu but the same issue also occurs with HassOS (that’s where I first encountered it using a serial PIM). When you connect the PIM, the new port is immediately reported by HassOS in Supervisor > System > Overflow Menu > Hardware but isn’t actually available for use by an integration until you restart Home Assistant.
As for reporting it, based on the response I received reporting another issue, I’ll leave it to someone else.
It’s been well over a week since I installed the Simply Automated USB CIM and I am pleased to report that, so far, it has been working as reliably as the serial version. No problems to report.
That’s great to hear, I figured the USB reliability issues were likely just due to shoddy windows drivers. Serial drivers in Linux are very well tested as serial devices are relatively simple and very commonly used by kernel developers so bugs there get fixed fast. This is one area where the Linux drivers are basically universally better than the Windows equivalents. Serial hardware manufacturers even like to sabotage their own official Windows drivers, FTDI and prolific are known to do this for example. Some like FTDI even went as far as to embed malicious code into their windows drivers which attacks counterfeit hardware.
Well for me life got busy as well between work and spending most weekends out camping getting out of the house. Now starting to hunker down for the winter, please let me know when you might have some time to test the PulseWorx IP UPB controller…
I’m just not getting along with this forum software. Meant to reply to Glenn’s post back on Aug 24.
Are there any ethernet IP UPB PIMs that have been validated to work with the UPB integration? I did not see any hardware based suggestions (only ser2net) in this thread or in the integration documentation.
The Pulesworx IP Gateway I have doesn’t currently work with the integration. I’m looking for a functional ethernet UPB PIM.
My HASS.io instance is now running in a VirtualBox VM physically far away from where the current serial PIM is located not to mention it still connected to the CQC HA software until I can transition all of the automation over to HASS.
Just as an added bit of information, the computer the HASS VM is running on is physically isolated as much as possible to prevent potential lightning damage (it’s also running Blue Iris NVR for the surveillance cameras and we’ve had 3 indirect lightning hits in the last 10 years) Network is connected via fiber optic, Computer is plugged into it’s own UPS. There will be no other wired connections, usb, serial, etc, to this box. e.g. a USB or serial UPB PIM connected to the power line. UPS will filter out the UPB signal on the power line if the PIM is plugged into the UPS so that is a non starter. Extreme, yes, school of hard knocks.
I’m heavily vested in UPB and and very happy with it’s reliability, this is one of the last hardware bits to solve before I can shut off the old CQC box.
Any and all thoughts or suggestions is most appreciated!
I apologize for not getting to this sooner. I just have not had the time in the last couple of months to relook at the UPB integration.
I reasonably “simple” way to get a UPB PIM is to connect a serial PIM to a Raspberry PI and use ser2net. You would need a Raspberry PI, Serial to USB converter, and a Serial PIM. On the Pi you would need ser2net which should be a simple pkg install.
My personal setup is a PIM connected to a USB port on a Windows computer through a serial to USB connector. I run ser2net on the Windows computer. (I’m not a Windows fan, however, we have a reasonably powerful media centre box in our home that I run Home Assistant on in a HyperV VM).
I had started writing the gateway code a while back. I slowed down because getting the code integrated into the UPB lib was requires a fair bit of refactoring. I do like @jameshilliard idea of a proxy though. I had not thought about that before. That might simplify the integration.
Has anyone tested the UPB integration with switches from PCS (instead of Simply Automated or Web Mountain)? Specifically the WS1D Wall Switch Dimmer (that’s the older version of the WS1DL).
Digi and other brands make serial to IP adapters. Or like others have mentioned a Pi could be used. You can probably find an old name brand one on eBay for a reasonable price.
If there are any owners of the WS1D, I would like to hear how this older model handles an LED load. Is the dimming performance satisfactory? If not, does it at least work well simply turning on the LED lamp to full brightness or is even that problematic (buzzing, flickering, etc)?
Basically a python script that acts as gateway client and socket server, I actually wrote a tracing debug proxy already for the pulseworx gateway when first implementing gateway support in my library, would just need to adapt it a little to make it a translation proxy.
No worries, I understand the challenges of life and time priorities!
Where did you source ser2net windows exe from? In the short term I could potentially do that. I have another Simply Automated PIM that I can put to use. Was originally used for troubleshooting and programming. I can run it on the same box that has my CQC software running.
Now that I have the Pulseworx gateway it makes it very easy to program new devices.
I also have a serial to ethernet adapter that I sourced off of Amazon that I can experiment with as a stop gap.
In the long run I’m after minimizing points of failure in complex communication paths. Sometimes there is no getting away from it.
On Windows I use nssm (Non-sucking service manager) to turn the ser2tcp into a Windows service that starts with the machine.
ser2tcp also does a couple more things than just serial to TCP conversion. It allows a second client to connect and take priority over the first client. I use that with some success when configuring using UPStart.
Take a look at config.toml in the github repo for some more details.
