@jameshilliard that is an interesting concept how do you envision a proxy working?
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.
The ser2net on Windows is one that I wrote. https://github.com/gwww/ser2tcp
I can share a binary with you if you like.
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.
Iâll take you up on that binary offer, thanks!
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.
The end. 
Whoop, whoop!!! 
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.
Have fun playing with UPB!
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.
Do you have any PCS Pulseworx switches?
I have 1 PCS lamp module. Everything else is Simply Automated.
Does it work reasonably well for dimming LED bulbs?
Iâm trying to get a sense of how well their devices fare with LED given that they promote the use of WS1DL over their older WS1D switches.
FWIW, all my switches are from Simply Automated, they donât offer a newer model for LED lighting but I havenât encountered any issues with their switches controlling LED loads. The one thing I believe the WS1DL has is âtrimâ which allows you to recalibrate the dimming range (since most LED bulbs donât really dim much below 20% and bottom out at 10%).
Yes it does. I have GE Relax HD bulbs (2 @ 1500 lumens) in the table lamp. And like you said, bulbs dim down to about 10% and in the case of the GE bulbs stay lit at 10% level until I hit 0. I am able to set the cutoff for the dimming level on the device via UPStart.
I have found that dimming results will vary depending on the quality of the power components in the LED bulbs.
1 Like
I was just thinking. I would hate for someone to try and read this thread. Itâs only 450+ posts. wonder if there is a way to split up in the future so itâs more manageable.
Forgive my absence from this thread. I occasionally logon and read the posts and had meant to respond to @123Taras about UPB dimmers and LED bulbs earlier but just never took the time to do it.
For a couple of years, every six months I would go down to the local Home Depot and Loweâs and buy several types of LED bulbs and test with our UPB dimmers for compatibility. I finally gave up doing that and now tell customers to go buy a couple of bulbs and test with their dimmers but make sure they have a receipt and can return the bulbs if they donât work well. However, I can provide some generalities.
First, we see several issues with LED bulbs with UPB dimmers. The most common issue is that youâll start dimming up and the bulb wonât turn on, wonât turn on, wonât turn on, then bang, it will turn on at some higher level, oftentimes in the 30 to 40% intensity range. Same when dimming down - it dims down but when it hits that 30 to 40% range, it turns off. PCS put in a feature in their units and in Upstart to set that minimum dimming level so that the dimming on the switch starts around that level. It somewhat works, but itâs not what I want to have happen. I would prefer to see the dimming go much lower. But, it works.
Another issue we see is flicker. With some bulbs, especially the cheaper bulbs, weâll see flicker while it is dimming up or down. I have even seen a few bulbs that would flicker sitting at a solid level.
I havenât seen much difference between the PCS, SA, or my switches on these tests, other than PCS has that one feature where you can set the minimum dim level.
Several years ago, Home Depot was selling some CREE bulbs. These bulbs worked the best of any bulbs I had tested, so I replaced all the can light bulbs in my house with these and bought several spares. However, I went back to Home Depot several months later and they no longer had these bulbs. Thatâs one of the problems I was running into when users asked me what bulbs to use - HD and Loweâs regularly change vendors, model types, etc. Also, the bulb manufacturers are constantly releasing new models so a bulb that worked well a year ago might no longer be available and you have to test their new model.
Typically, weâve had very good luck using CREE bulbs with UPB dimmers. Also, as @batwater said, weâve had decent results with GE Relax (but not all bulbs in that family). I also had seen some good results with a particular Sylvania bulb but not others. Iâve had terrible results using the cheaper brands such as Ecosmart, Feit, etc, even when they are marked as being dimmable. I havenât tested all models, so some of you might have good luck with some of these cheaper bulbs. But, it is still the Wild, Wild West when it comes to LED bulbs - just test a few before you change them all out.
A couple more comments. Be careful on really light loads. If you have a really light load on a dimmer, say 2 -3 W, the dimmer might not completely turn off the load. Thereâs enough leakage to keep the bulb lit very dimly. If you run into this, contact me and I can give you some suggestions.
Not specifically related to LEDs but if any of you are running backup generators, make sure the frequency of the generator is spot-on at 60Hz. UPB devices are very sensitive to frequency, especially if the frequency is higher. UPB switches start having issues if the frequency gets above 60.3 Hz. Believe it or not, weâve actually seen power grids (most notably in Florida) where the frequency got above 60.3 Hz. Iâm not sure how the regulators even allow that to happen, but weâve seen it almost a dozen times in Florida (once in TX). But, I have received several calls from folks using generators with this issue. Set it to 60 HZ and the issue goes away.
As most of you know, we canât get Simply Automated switches (or any other devices) - supply issues out of China. And, I canât get any information as to when this situation will be resolved. Also, as most of you know, I take SA switches and reprogram them with Gen2 firmware and resell the devices with my own part numbers. Since I canât get SA devices, I am reselling PCS devices so that my customers can at least get devices. There are some differences in features between SA and PCS devices but from a UPB perspective, they are totally compatible.
If any of you guys on this forum need UPB devices, contact me directly and I can get you better pricing on the PCS devices, due to all the support you are giving UPB. If you want to test a PCS device, I might have a couple of used ones laying around.
Just some general information that might be of some value.
1 Like
By the way, one more comment. Over the years, I tested many non-UPB dimmers with LED bulbs and saw many of the same issues.
Thanks for the information.
Based on my own observations, Trenz ThinLED Recessed Lights (manufactured by Lightline) dim fairly smoothly down to about 10% (although itâs a barely perceptible difference from 15-20%). I have several of them in two models (fixed and gimballed Retina model which has even better dimming characteristics) and both work well. However, even at 10% itâs still fairly bright and not candle-like compared to an incandescent bulb. Thatâs why the vanity lights in our master bathroom are still incandescent candelabra bulbs because when theyâre dimmed to 5% theyâre very good night lights (after 23:30, a motion sensor turns them on automatically to that level).
Three recessed lights from Bazz change color temperature based on their brightness level. That works nicely but they âstutterâ a bit when dimmed. They also flicker noticeably when thereâs any UPB traffic.
I have several Philips LED bulbs (PAR20 and PAR16) and they dim smoothly (again, only down to about 10%) and donât flicker noticeably when thereâs UPB traffic on the powerline.
Worst performers are two recessed Luminus lights I bought many years ago from Costco. They sat unused until recently when I used them to replace two halogen pot lights. Ugh. They donât turn on/off until theyâre well above 10%, donât dim smoothly, and produce a lousy color temperature at anything below 75%. Similarly, two Luminus bulbs, also purchased years ago, have the same behavior. Basically, old tech with just enough dimming capabilities to make the claim they can be dimmed.
FWIW, the supplier Iâve used in Canada for Simply Automated devices stopped carrying their products about a half-year ago. Fortunately, I still have a few extras, waiting to be installed (just as soon as I re-wire the circuits to provide a neutral line ⌠curse these âswitch-loopsâ in old homes).
So, recently, I added a couple scene controllers to my UPB network. I noticed that when I did that, I started getting communication timeout issues in the HA logs. The message looks like this:
Logger: upb_lib.upb
Source: /usr/local/lib/python3.8/site-packages/upb_lib/upb.py:148
First occurred: 5:17:15 PM (2 occurrences)
Last logged: 5:17:26 PM
- Timeout communicating with UPB device âLiving Room Scene Controllerâ (79_31_0)
- Timeout communicating with UPB device âMaster Bedroom Scene Controllerâ (79_33_0)
I would assume that this is because the scene controller is not a light switch/outlet, nor a scene. As such, the request for information is probably not returning any useful information to the HA integration. Is this a known issue? What should I do in this instance to clean up my HA installation, or is there a bug that should be filed? Thanks.
What are the actual devices - manufacturer, device type, etc. - I might be able to deduce something from that.
A debug log will be helpful to look further.
Thanks for the reply, Glenn. They are both HAI 38A00-1 6 button room controllers. The debug log is here:
https://pastebin.ubuntu.com/p/6g9kWhmKmm/
Thank you.
Still poking around on this one, my best guess is that the 6 button controller does not respond to a âget_statusâ request. Which makes sense since the status that is being polled is the dim level of the lighting which does not exist as this is a non-load device. Sending dim and other commands to this device also doesnât make sense either. I donât think that thereâs any harm in leaving them in if the warnings donât annoy you too much. If you wanted to you can edit the UPB export file from UPStart and remove these two devices.
Does that sound right? What I have read about the devices seems to be consistent with what I said here.