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.
A big thank you to @gwww for the assist yesterday evening! It works, it works!!! I now have UPB up and running but it was a journey of discovery…
After some back and forth via email to solve a missing dll and a recompile of ser2tcp later, I was able to achieve partial connectivity from the HASS UPB integration to a ser2tcp connection running on my old CQC windows box. It was making the connection and then quickly hanging up in a continuous loop of connect disconnect. The problem was manifesting as another connection interfering with the serial port. At that point we had to stop for the evening and catch some ZZZs…
Flashforward to today, after reactivating some long dormant synapsis to serial port knowledge and some head scratching time later I figured out the problem. There is a universal law of serial port physics that cannot and will not be violated and that is if a serial port is set to hardware handshaking it absolutely will not behave properly from a connection expecting XON/XOFF. Doh!
How did this happen? Well, many many years ago I started using a utility called Serial Port Splitter which allowed me to map a physical serial port to multiple virtual ports. This was originally driven by the need to split serial data from a Davis Weather Station to the CQC driver and to Virtual Weather Station to publish my weather station data on the Weather Underground. Later I started mapping all ports this way so that I could fire up Realterm, hercules, HyperTerminal (pick your RS232 terminal of choice poison) and troubleshoot I/O. This was particularly useful back in the day when I was deciphering X10 RF signals coming from their security door/window sensors and the DSC alarm panel interface. The terminal program (or other utility tied to the hardware in question) could be left up and running while I/O occurred, even allowing me to interject data into the stream.
So flash forward to yesterday evening, I paused the driver in CQC and mapped ser2tcp to a virtual comm port that was set for hw handshaking. The physical port settings in Serial Port Splitter define the communication parameters for the port forcing the virtual comm ports to the same settings.
I have to admit I don’t really understand what you did. It sounds like we gave each other enough clues to solve this! Congrats! Besides myself, you are the first person to use ser2tcp.
It was definitely a tag team effort and glad that you had ser2tcp available to share not to mention the incredible result of the UPB integration! I already have my first automation tying the DSC via Eyzeon kitchen garage door binary sensor to a UPB light in my garage. Auto on when the door is opened. I have several others like this that I need to get migrated, one step closer to full HASS for the batwater castle’s HA brain.
