Hi All, new to HASS, moving from CQC; I see some old friends here!!!
I just purchased a PulseWorx gateway with the hopes of connecting from HASS to the gateway via IP. When I configure the integration it never connects and slows HASS down to a crawl (repeat disconnect errors in the log.) so I have removed.
I’m running HASS on a Pi 4. I may have been mistaken in understanding that the gateway would function the same way as the IP PIM from PulseWorx.
I am able to connect to the gateway via Upstart or from the phone app and control my lights so I know it is configured and working. The setup documentation for the gateway has you set up a user ID and password for the gateway, that may be part of the problem but I don’t see any documentation with regard to entering said info for HASS to process with.
Any suggestions on how to make this work would be most appreciated. I’ll be reaching out to HomeControls support tomorrow to get some feedback there as well. I may have to return the gateway and purchase the PulseWorx PIM IP instead. Confirmation that the PIM IP works with this integration would be appreciated.
It’s probably just the initialization process being a little different between the different types of gateways, I’m actually working on that right now as part of my UPB pulse mode library since it needs to be able to put the PIM into pulse mode. It shouldn’t be that difficult to make it work with my pulse mode library or @gwww’s message mode library. If you want to port forward it and PM me the IP/port I can try and take a look at what’s going on.
Edit: I pushed an update to my library adding some basic PIM register read support.
It would appear that the gateway doesn’t like what I send so it just disconnects. When I get some time I’ll look for some gateway development docs and see what it says. If you happen to find some first that would be great There is surely some code to be written to work with the gateway. If its a tweak I’ll get on it. If its more then we have to see.
There’s a login sequence required and messages to the PIM are prefaced with a command byte. The response from the gateway is also different. It’s not a trivial piece of work to get this working and I don’t have a gateway to test with.
I’ll ponder this for a bit. Happy to take well-constructed patches to the UPB lib
Edit: It appears that the PIM-IP uses the same protocol as the Gateway.
I’m happy to remotely share my gateway to work through this. My only other choice is to attempt to return the unit and purchase the PIM-IP. I would rather hold on to what I have if at all possible plus this expands the compatibility of the integration and allows for more secured remote communication should that use case be desired by someone.
Ok, thx, when I get some time I’ll reach out. Or, if someone else picks it up and integrates, that’ll work too.
I’m not 100% sure, but what I understand is that the PIM-IP has the same protocol requirements as the gateway. The TCP support in the library now is only “ser2tcp” support which means that connecting using TCP is straight up like its talking to a serial PIM without login etc.
Yeah, I don’t think it will be too difficult to support, I’ve gotten enough decoding working in my upbshark tracing tool that I think I should be able to handle it. It might actually be harder handling it in the upbshark tracing tool than in the normal UPB client library due to the double sided state tracking being more complex than when using a normal client library. I’ll try and see if I can get a client/protocol unwrapper working with it today.
Well the PIM-IP from my reading of the upstart code uses PacketCheckTelnet for its packet processing while the pulseworx gateway uses PacketCheckGateway. I’m pretty sure the PacketCheckTelnet codepath is what’s used for the plain ser2tcp/ser2net serial PIM bridge protocol. I’ve mostly been testing my upb pulse library using a ser2net bridge and serial/USB PIM myself so I’m quite sure that the outer gateway protocol is different from the normal simple TCP bridged serial protocol. The good thing is that the inner protocol encapsulated within the gateway protocol appears to be identical to the serial/ser2net bridge protocol so a protocol wrapper/unwrapper along with auth handling should be all that’s needed as opposed to a completely separate implementation of the base serial/TCP bridge protocol handler.
enum Hardware {
HardwareUnknown,
UPB_PIM, // RS232 PIM
UPB_CRR, // Obsolete 3-phase interface
USB_UPB_PIM, // USB PIM
VSP_UPB_PIM, // USB PIM via virtual serial port
NETWORK_UPB_PIM, // PIM-IP version 1
WMT_RUC, // Web mountain RUC
NETWORK_UPB_PIM2, // PIM-IP version 2 (Pulseworx Gateway)
VSP_T24_TIMER, // Timer via virtual serial port
NETWORK_T24_TIMER // Timer via network gateway
};
case UPB_PIM:
case USB_UPB_PIM:
case VSP_UPB_PIM:
case NETWORK_UPB_PIM:
case WMT_RUC:
if (m_IsTelnetConnection)
cbCmdRemove = PacketCheckTelnet(pDecode, cbDecode);
else if (pPIM->m_InPulseMode)
cbCmdRemove = PacketCheckPIM_PulseMode(pDecode, cbDecode);
else
cbCmdRemove = PacketCheckPIM_CommandMode(pDecode, cbDecode);
break;
case VSP_T24_TIMER:
cbCmdRemove = PacketCheckTimer(pDecode, cbDecode);
break;
case NETWORK_T24_TIMER:
cbCmdRemove = PacketCheckGateway(pDecode, cbDecode);
break;
case NETWORK_UPB_PIM2:
cbCmdRemove = PacketCheckGateway(pDecode, cbDecode);
break;
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.
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.
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?
There is surely some code to be written to work with the gateway. If its a tweak I’ll get on it. If its more then we have to see.