Continuing the discussion from BLINDS // Who is winning the race?:
Has anyone tried to integrate the Pella Insynctive products? Their integrated motorized blinds and integrated open/closed/deadbolt sensors look nice, especially for new home construction and renovations.
Looks like you need their hub to communicate with their devices, but then their hub can communicate over Z-Wave to other HA controllers? Interesting…
I’m waiting for my local pella store to get them in so I can check them out. I’ve had my eyes on these for a while
For those interested, there’s a tiny bit more info here:
http://insynctive.pella.com/home-automation-system
@sidjohn1 Let me know what you find. In a year or so we’ll be embarking on a renovation of the back of our house, which will mean a new sliding door and at least 8 south-facing windows. I’m seriously considering these integrated motorized blinds.
It’s a 433/z-wave bridge. Those have been fairly common in Europe, it’s interesting to see one for the U.S.
One unusual aspect: the bridge itself is battery-powered. It will have a 4 to 6 month battery life if you issue just a few commands per day. If you poll every 5 minutes, you’ll be very unhappy, as the battery would likely last less than a week.
I think the bridge is mains powered with a battery backup. From the product guide under setup:
Plug BRIDGE into an electrical outlet (light will turn green and then flash blue).
But speaking of batteries, does Pella offer a mains powered option for their blinds and/or sensors? Seems like they should… if I’m already tearing out a window, it’s usually trivial to drill through the frame and pull power.
The between the glass blinds/shades have a solar panel that will recharge the battery if it gets direct sunlight. Otherwise there is a power cord you can connect to it to charge it.
Anyone have any more information on this? I’m replacing some windows and seriously considering adding this option, but I see that Wink is the main platform they support. If the bridge showed up as “contacts” in SmartThings, I’d be fine, but who knows!
Keeping the thread alive. I’m about to pull the trigger on new Pella windows and doors with Insynctive and use Smartthings. From what I can find the Pella wave bridge is integrated with Wink to date… wondering if/when Smartthings will make the same move?
I don’t know that anyone has ever tried to connect the bridge to ST. It might just work. The insynctive sensors are all very basic, and the bridge is a Zwave device, if I remember correctly.
At the very least, it may be possible to write a device handler for the bridge… again, I don’t think anyone has tried.
We are slowly moving toward putting an addition on the back of our house, and I am tempted to go with Pella also. Let me know what you find.
I would not hold my breath for an official integration from ST. These things seem to take forever.
Note: I found out the built in sensors are only on a certain model line–I don’t recall the name, but it was the wood ones. You can get other sensors, but I think they are external and visible.
I have just installed a Pella Designer door with the lock and door sensors built in, and connected the Insynctive Bridge to my ST Hub.
So the good news… it was immediately recognized.
Bad news… it was recognized as a “remote” and doesn’t show anything
So the “remote” part sort of could make sense, as the bridge is also used for motorized shades etc (I don’t have those). But since that’s not useful, I thought I’d try making a device handler.
So unfortunately I’m having little luck and would love some pointers from device handler pros.
Here’s what the device reports:
Data MSR: 013D-0003-001F
Raw Description zw:L type:0100 mfr:0000 prod:0000 model:0000 ver:0.00 zwv:0.00 lib:00 cc:85,86,72,21
So I figure most of the good commands are going to be the “manufacturer proprietary” one. But since I only want to parse open/close lock/unlock commands, I thought reversing the incoming events would be easy.
Unfortunately, none of these events seem to be arriving. I build a crude handler with this core function:
def parse(String description) {
log.debug “Parsing ‘${description}’”
def cmd = zwave.parse(description)
if (cmd) {
result = zwaveEvent(cmd)
log.debug “Parsed ${cmd} to ${result.inspect()}”
} else {
log.debug “Non-parsed event: ${description}”
}
return result
}
Which as I understand should show the results of any received events in the Logging tab. And when I test the z-wave connectivity of the device, it appears to work, and I receive the following event in the logs:
Parsing 'zw device: 35, command: 2003, payload: 00 ’
So that seems to show the basics are working. And pressing the other test function on the bridge shows the device is in fact communicating with the door sensors. But nothing seems to be being passed on via z-wave, so I’m stuck. Are there devices where a hub has to “subscribe” to events??
Any suggestions?
I wish I could help…
I had the bridge working with Pella window/door sensors and Vera with general Z-wave practices. You have to pair each sensor to the hub individually via the bridge. So the bridge needs to be paired first and shows up as a remote that really doesn’t do anything, and then each sensor also gets paired with it’s own individual process (via the bridge) as it’s own device. I tried several months ago to add to SmartThings in the same manner that worked perfectly with Wink and with Vera, but couldn’t get it to work. That tells me that we probably just need a Device Handler written for SmartThings for the Bridge, but I don’t know the first thing about how to start that. Is there anyone we could work with to do so? Pella advertises Z-wave compatibility, but SmartThings doesn’t seem to be liking something…
I have just posted v1.0.0 of a wired Pella Integration that I completed.
Please see this thread: [RELEASE] Pella Insynctive Integration
The github is https://github.com/gnieboer/PellaBridge
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:
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
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)
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.
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.
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
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.
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.
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
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.
All, I’ve updated the Pella Bridge to be compatible with Edge Drivers
The driver channel invitation is: SmartThings. Add a little smartness to your things.
Current the shades are not supported, please message me if you need that.
So which devices do come through the integration? The sensors?
It can support anything that Pella Brisge device can, so as far as I can tell that’s door locks, door open sensors, garage doors, and shades. Right now I haven’t enabled the shades in the new sensor but I can if there is a demand. I don’t own any so can’t test them.
I’ve been considering the Pella sliding patio door with the integrated shades/blinds for a while now (many home improvement projects ongoing since the start of the pandemic!), so I’d be interested if you do add the shades. I don’t own yet so can’t alpha test with you, though. I’m sure there are others here who would be interested as well.
The automated integrated shades, BTW, are outrageously expensive. I couldn’t justify it and went with the manual ones in our double patio door (it has sidelights so it would have been 4x shades)
I installed the Pella Insynctive shades in our theater room and one of our kids’ bedrooms. I’m loving the automation. Especially in the theater how I coordinate them opening closing with theater activities and time of day.