[RELEASE] Pella Insynctive Integration

Devices & Integrations
1

All,

I’ve just posted the 1.0 version of an integration for Pella Insynctive Bridges, including Door sensors, Door locks, Garage Doors, and Blinds/Shades.

The code is all here: https://github.com/gnieboer/PellaBridge

Here’s the README from the repo:

Pella Insynctive SmartThings Integration

Version: 1.0.0

This a project to bring integration of the Pella Insynctive system into SmartThings.

The ZWave capability of the bridge is currently not compatible with the ST Hub, at least as far as I’ve been able to accomplish. The bridge can be paired, but the devices themselves which should “pass through” the bridge to the hub can not.

Instead, this project uses the wired interface to accomplish the same objective. It is not a simple setup, however. The bridge uses Telnet on port 23 to accept a single connection and send/receive commands. ST cannot connect directly to a TCP socket, so this integration requires a REST proxy Docker container to accept calls over HTTP and convert them to raw TCP and vice versa.

If you are not familiar with docker containers and using PuTTY to connect to devices, this integration might be a challenge.

There is a “tamper” warning if the cover of the door sensors is removed. The Up and Down commands for the shades will send them to the “user programmed” open and close positions. The full set of commands is in the device handler code, and could be implemented if the user wants something different, but I kept the DH interface simpler based on my preception of real user needs.

LIMITATIONS/ISSUES:

  1. Pella Blind/Shades have not yet been tested with a real shade, it “should work”, but could likely be improved.
  2. Pella Blinds have a tilt command which is not yet implemented in the device handler (0x68 and 0x69), but will be sent by the proxy.
  3. I received extraneous battery level “4%” / “5%” readings which eventually disappear. These appear to be coming from the Pella Bridge itself.
  4. I have little time to provide any kind to troubleshooting / technical support for this image. Pull requests are welcome.

Installation

Step 1

Ensure the bridge is not paired to your Zwave hub. A factory reset is not sufficient

TEST : When the bridge is unplugged/replugged, the blue light should flash after the green light comes on

Step 2

Pair the bridge with the Pella Devices in the “No Home Automation” mode use the instructions for the Pella Bridge product guide and the product guides for each of the compatible products. Note that if you have previously tried to pair the bridge to your hub, you will need to specifically unpair the device, a factory reset does not accomplish this. Range is not as critical for pairing as it is for zwave, the Pella devices use 433MHz and have better range (but no mesh network), so in a normal sized house bridge placement should not be a major issue.

TEST : When the door/lock is toggled, the bridge should chime (assume you haven’t specifically turned the chime off with the dip switches)

Step 3

Change the IP address to the bridge. The default IP is 192.168.100.121. Plus bridge into your LAN, and use Putty (NOT windows telnet) to telnet into the device. You should see “Pella Insynctive Bridge” as a banner on connect. Enter the following command:

!BRIDGESETIP,$192.168.000.002

Obviously use your preferred LAN IP address. Note the leading zeros. This IP will persist after a factory reset.

TEST : Reset device and connect to it via Putty. Enter the following command to check the number of paired devices matches:

?POINTCOUNT

The number returned should equal the number of devices paired in step 2. Disconnect from the bridge.

Step 4

Install Proxy Container The proxy is a .NET Core Linux container, and requires two environment variables to be set during container creation: HUB_IP_ADDRESS : The IP address of the smartthings hub BRIDGE_IP_ADDRESS : The IP address set in the previous step Ensure the addresses will both be reachable from the proxy. They need not be on the same subnet if you have a segmented LAN, but DO NOT expose the address to the Internet as the bridge has no security (and therefore the proxy does not either). The proxy connects to the bridge on Port 23, connects to the hub on 39500, and receives from the hub on the port of your choice (32781 by default command below), so those ports need to be open Use the following to pull the image from Docker Hub and get it running on the server of your choice, or the equivalent in your favorite Docker GUI.

docker pull gcndevelopment/pellabridge
docker run --name pellabridge --env "HUB_IP_ADDRESS=192.168.0.100" --env "BRIDGE_IP_ADDRESS=192.168.0.101" -p 32781:80 gcndevelopment/pellabridge

The proxy will immediately connect, so ensure you have disconnected from any manual connections you have made. The container should gracefully handle TCP connection issues, including bridge power offs/disconnects. (It will complain in the console window, but should eventually re-connect). It will keep the connection alive with a 4 minute ping, which is therefore the longest window in which a push notification from the bridge might be missed.

TEST : Go to a browser and check:

http://your.proxy.ip:32781/api/PellaBridge [Expected response, json “Hello”, “World”]

http://your.proxy.ip:32781/api/PellaBridge/status [Expected response, {“version”:“A58”,“mac”:“00:XX:XX:XX:XX:XX”,“connectTime”:“2020-06-06T20:19:38.2991876+00:00”,“ip”:“192.168.0.101”} or similar]

Watch the console output of the container to see the data being transmitted as expected for the second command.

Step 5

From the /groovy subdir, install the device handlers you have physically, as well as the Pella Insynctive Bridge smart app

TEST : Make sure you can see them in your IDE

Step 6

Configure the Bridge in the app. Enter the proxy’s IP address (NOT the bridge) and port, and the enter “Next”. The app will query the proxy and get information all the devices and install them. Once you see the number of devices installed, click “Save” The device will have preferences populated. You should not have a need to change them unless you move the hub or reprogram devices (though it may be simpler to just delete them all and re-configure the smartapp) The bridge itself will not appear as a device since it really has no function beyond enabling the connections.

TEST Observe that the number of installed devices matched expectations.

Step 7

Devices of the same type will all have the same name, you will have to figure out which is which and rename as appropriate.

TEST You are now complete… ensure that the device are present as expected, and in the expected state. Ensure that data is being pushed by opening a door etc manually and observing the status change.

TROUBLESHOOTING

The REST API is a simple one, entirely GET commands, so straightforward to access directly and bypass ST.

{id} = The Pella Device ID. Numbers starting a 1, see device preferences for each device’s code

  • GET: api/PellaBridge (Hello World)
  • GET: api/PellaBridge/status (Gets bridge status as JSON)
  • GET: api/PellaBridge/enumerate (get all devices and their current status)
  • GET: api/PellaBridge/battery/{id} (gets battery status as number)
  • GET: api/PellaBridge/devicestatus/{id} (gets device status as Pella code, see dev handler code for lookups)
  • GET: api/PellaBridge/devicestatusstring/{id} (device status as string)
  • GET: api/PellaBridge/setshade/{id}/{value} (send shade command, 0-100 is % open, >100 are special commands, see DH code)
  • GET: api/PellaBridge/pushdevice/{id} (send a fake push notification to the ST hub, used only for help troubleshoot)

A combination of container console logs and ST logs should be plenty to identify where a connection might be failing. Use the last API call in the list simulate opening the door/lock. If pushes are failing, restart the container and see if it fixes it. If that is required often, please try to capture errors from the console and post them.

I’d recommend starting from the bridge and working from there to the Hub. Examing the container console to be sure the calls are being received and responded to by the bridge, then manually engage the API and confirm that the container is returning expected JSON, then finally ensure ST configuration is correct.

2

@gnieboer This is awesome! Thanks for creating this. I’m not familiar with telnet (yet) but was able to connect to my Insynctive bridge via Windows Telnet and query device statuses and stuff after looking through your code. Questions:

  1. How did you find out what the various commands are that the Insynctive bridge recognizes? (like POINTCOUNT)
  2. Do you know of a way to get the bridge to provide the name of a device as set by the user in the Pella app (e.g. “Front Door”) using telnet commands?

Garrett

3

@gcookaustin,

Thanks!
1- I did a lot of googling, and found some support documents for 3rd party integrations that gave me enough to put the pieces together.
2- I do not, I don’t use the Pella app so never tried to do that. If you figure it out, I’d be more than happy to add those commands to the app’s API. Obviously I’d certainly start with some guessing based on how the other commands work (?GETNAME 001, etc). [Edit: it’s possible the names are only stored in the Pella App, and app translates to the device ID before sending to the bridge]

4

I just found some documentation on the Pella website for several pro-installed home automation controllers. The fileset for AMX contains the commands you are using plus a command “?POINTID-XXX” to get the serial number of a sensor. POINTID might be a better cross-reference since it won’t change after a factory reset (as I’ve had to do a couple of times before on the Pella bridge). The documentation for AMX and other systems implies that there’s not command to get the device name from the hub so like you said it’s probably only available from the Pella app. I actually don’t yet have a smart hub but am getting Hubitat soon and plan to use or write a telnet driver for getting the Insynctive info – supposedly Hubitat allows telnet connections from the hub.

5

You are probably right, ?POINTID might be the way to go.
Best of luck on the Hubitat driver, I hope this code gives you a place to start.
Mine has been pretty reliable over the last couple months, key thing is managing the timeout of the connection and making sure the service doesn’t crash on a transient network error.

6

Let me know how you make out getting this to work on the Hubitat. I’ve been looking for a solution to move away from wink.

7

Will do. So far I can connect to the Insynctive Bridge and the Hubitat driver I’m working on can pick up on when a door opens/closes and set the state for that child device. I’ve got some cleanup to do and make it more reliable and plan to post something in a few days on the Hubitat forums.

8

I’ve just added a driver for the Pella Insynctive Bridge, using Hubitat’s built-in telnet capabilities. The code is available here:

9

FYI to all, there is now an Edge Driver for this integration. Requires an update to the bridge. See the same github etc for details. Shades are not yet included.