What is your ability to patch your system if I did provide some code to test? It is possible that something reasonably simple could be done (still looking). It would required for you to change out one of the files in the UPB library. That’s easy to do when running on a PC/Mac but more challenging when running on a Pi. I believe that @123 has done something like that and might be able to give some direction (I do all dev work on a Mac and don’t have to patch files).
I’m running HASS on a Pi and accessing remotely via a Mac. With some guidance I’m sure I can swap a file out. If @123 can provide some guidance I can figure it out.
Python virtual environment or docker?
To be honest, I don’t know. I installed HASS from a downloaded image for a Pi 4 and didn’t think anything more about.
Got a bit busy yesterday with cleaning up config flow for one of the home assistant integrations I maintain so I didn’t yet have a chance to get a pulseworx gateway client unwrapper working yet, I have remote access set up to @batwater’s gateway along with a dev environment that I can use to test stuff if you have something already. Going to try and work on a protocol unwrapper myself shortly otherwise.
1 Like
Based on your description, I believe you installed Home Assistant OS.
It’s distributed as a disk image (for specific hardware platforms, such as Raspberry Pi) containing Home Assistant Core, Supervisor, and an operating system (and a few other things).
I just pushed some code to a gateway branch. Untested. The code is to wrap/unwrap PIM commands with gateway wrappers.
Missing is login logic and something to turn on the gateway mode in the library. It’s a start.
This will require upstream HASS code changes to support turning on “Gateway mode” and to supple userid/password is auth is being used.
Here is a link to the branch. Totally untested, just in case you missed that above 
Actually I did a small test to see if regular PIM stuff works. It appears that it does. https://github.com/gwww/upb-lib/tree/gateway
Ah, cool, that’s the part I hadn’t looked at extensively, I’ve worked out the auth logic already in my upbshark proxy so shouldn’t be much trouble creating the client auth capability from that. I’ve been refactoring my upb pulse library to split out the different protocol backends so that I can add gateway support without interfering with the normal TCP socket protocol.
I’ll take another look at your auth code to see how to refactor it into upb-lib.
If you could take a look at my change for the gateway that would be helpful. I’m working off a pretty poor document without examples. Curious, are all packets null terminated? And within, when there’s PIM packet, is it a full PIM packet the PU header, content, and PIM checksum?
@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?