@batwater have you install Python on your Mac? Version 3.7 or higher (although 3.6 likely OK). If so I’ll likely get you to run some tests against your gateway. No rush, won’t be for a few days (or more).
Yeah, using it as a reference, packets are null terminated but I think after auth is complete you have to switch to using length prefixed based decoding for it to work correctly, auth sequence does not use length prefixed commands however.
Yah, thanks. The reason I put the raw_mode in was to switch between trying to interpret packets at the protocol layer or just passing them up to the next layer. raw_mode would get used during the auto phase. When auth is complete then would switch out of raw_mode, meaning packets would be parsed a bit at the proto layer. So far it’s a minimal wrapper and minimal changes to the proto code.
Yeah, I was using a similar approach in my proxy to switch decoding mode at the end of the initial auth sequence.
I’ll get python installed first thing in the morning.
I’ve been testing with @batwater’s pulseworx gateway and have a working protocol wrapper which allows for my pulse library to do register dumping/UPB password cracking and essentially everything else it can do with normal PIM’s. I’ve noticed the pulseworx gateway seems to crash randomly when you send it improperly formatted commands, if I had to guess based on how the protocol works it’s probably a buffer overflow or something along those lines, maybe @webmtn knows someone at pcs who might be able to make the firmware a little more resilient when it comes to error handling. I think the bug is in the gateway’s TCP socket protocol command parser.
You could try [email protected]. I let them know a long time ago that we were working on the UPB integration for HASS. I didn’t hear anything.
I’ve had a couple of discussions with JamesHilliard and have made one of our RUC-02 IP controllers available to him for testing. I’m happy to do the same for Glenn, if interested. Our controller is a small Linux controller running a serial to TCP convertor, so that you can use the RUC as an IP PIM. Works quite well and I have a lot of installers using it for remote UPstart (and offers many other features). I practically never use a serial PIM or USB PIM by themselves anymore - I almost always use the RUC as an IP-PIM. (The RUC uses an external serial PIM - the serial PIM circuitry is not built in to the unit).
1 Like
Glenn did you ever get a chance to take a look at this?
Yes, but. I’ve written the code. I have not tested yet. I hope to get some more time this weekend or into next week. Work got busy… I will ping you direct when I think I want to do some testing.
I just wanted to come here to say thank you for your hard work on this! After using HomeSeer for a while, then moving over to OpenHAB as it became a solid platform, I always regretted not having the ability to import the .upe file when setting up devices. That was a major piece of functionality in HomeSeer that I missed in OpenHAB. I had always wanted to try out Home Assistant, as it seemed to be the more active platform for development. However, the lack of UPB functionality here kept me solidly running OpenHAB. I randomly checked again to see if UPB integration had been developed and was delighted to see it now. I quickly spun up a docker container on my Synology NAS and had everything that had originally taken me weeks to setup in OpenHAB up and running on Home Assistant in a Day. I’ve been really impressed with Home Assistant so far, and it wouldn’t have happened without you fine folks here.
Out of curiosity, would it be possible to configure this integration to create ‘Fan’ Entities for any devices with the word ‘Fan’ contained in the device name? I have 4 switches in my house that control ceiling fans. Unfortunately, because they are imported as lights into Home Assistant, my Google home integration breaks and tries to control the fan as well when turning the lights in a room on or off. I have tried to setup a template to change the way that these switches appear to Google Home, and this works to split them out, but then I can’t assign those entities to an area in Home Assistant, as that is not a possibility at this time. This fan entity would probably only need to support state, turn on, and turn off functions (no need for the speed, oscilate, etc. functions, since the device is just a switch and not capable of speed settings and such).
Also, I have ordered a UPB outlet that should be delivered next week. I was curious if this integration would be able to handle it, as it’s not a light, but instead more of a switch? I don’t know how an outlet displays in the .upe file yet, but would be more than willing to work with someone to get it integrated when I get it installed.
Thank you so much for your hard work on this. Please let me know if there’s anything I can do to help. I haven’t done a lot of programming in python, but I’m always willing to learn.
Sounds like a device_class for fan is needed? Or maybe there is one? Not sure. Also, this sounds like something you’re going to have to take up with the higher up devs.
Next WTH … "WTH can’t I assign an area to a fan template? "
I bet it’s an easy change for someone like frenck, but getting someone to do it is going to be tough.
You could always file a feature request. Maybe you’ll get lucky.
Maybe someone else has a better idea.
What is the make and model of this device?
It looks like the light and scene classes are the only ones supported right now. That’s the main reason why I was asking about the possibility to add support for a fan and a switch class.
As far as not being able to assign entities to areas… it drives me crazy. From what I have read, areas are fairly new still, and having the ability to assign individual entities to an area is on the roadmap, though not yet implemented. Right now, only devices can be assigned to an area, and all entities tied to that device tag along. Since using a template to override the light class and make these switches look like fans in Home Assistant only creates entities (and not devices), I can’t assign them to areas. If I’m incorrect here, I would love to be proven wrong. 
Where would I file a feature request? Thanks for your help.
They are all HAI (Leviton) 40A00-1 15A Relay Switches.
The new outlet I have coming is a Simply Automated URD-30 Receptacle.
The best fit for the Relay Switch is not light (as it’s currently being modelled) but a switch. There is a fan but the Relay Switch doesn’t qualify because fan supports speed and direction.
The best fit for the Receptacle is also a switch only because Home Assistant doesn’t have a model for an outlet.
Nice that it is kind of working!
It’s unlikely that the entity type would ever be selected from something in the name of the device.
It could happen that switch entities get supported. That was a discussion during initial implementation that non-dimmable devices get represented as switches. A switch only has turn on/off, no other functions. However, a light is treated just like a switch (by the UPB integration) when the device reports that it is not dimmable.
I’m not understanding what is broken with Google Home, but I don’t use the Google Home integration with my setup. It sounds like a config problem to me as each UPB entity is able to be individually controlled.