Premise Crosslinked Thermostats and Manual Control

Motorola Premise

kzboray

Member
I have 3 AprilAire 8870's that work very well with Premise. On occasion it is nice to be able to make changes manually on the thermostats themselves. Normally I want 2 of them to have the same settings. I was thinking that I could setup PropertyChange events for each of the Objects:

HeatingSetPoint
CoolingSetPoint
FanControl
HeatingStatus
Mode
Etc.

I was wondering if anyone else had done this and how you had gone about it.

------------------

Also I was wondering if anyone was in contact with or could contact "John in VA". I was hoping to get the source code for his Insteon Driver and have a friend look at it and hopefully finish up support for X-linked devices.

Kaz
 
If you can explain to me how the Insteon thing is supposed to work...normally, I'd be grateful

You might try giving John a PM
 
Chuck,

Thanks for your interest. I have tried to PM John with no success. I sent one out about a month ago and have not heard back.

The current driver has very limited support for cross linked Insteon devices. Insteon allows you to virtually connect as many switches together as you would like. 2-way, 3-way switches etc. This is very simple to do; you simply hold down the paddle on the first switch (A) for a 10 count, and then do the same on another switch (B). Now you repeat the process in reverse (B) first then (A). Now whatever action you enact on either switch is mirrored on the other. This includes the switches local LED indicators.

The current driver supports single button switches with the exception of the status LED's on the switches themselves. Each pair or more of cross linked switches has a master switch, and a slave or slaves. The master is physically wired to the load, while the slaves are not. Currently to activate cross linked switches you select the master switch in Devices/CustomDevices/InsteonRoot/SwitchLincRelay_xx.xx.xx and add a ConnectedDevice which links this master switch to another Insteon switch. Programmatically you can now send a PowerState=TRUE to the master device and the attached load comes on. However the status LED on the slave/s device remains in the off position. Sending a PowerState=TRUE to the slave does nothing. The second part of this is manual control. If switch (A) or (B) are manually turned on or off, their status in Premise is not always updated. If you send a RequestStatus on the individual devices this will update with the proper status, but sometimes the Insteon Driver will hang if this is done too often. If the driver hangs you lose all communications with Insteon devices and have to shut down both the Insteon service as well as the Premises server, and then restate to get things working again.

The second related problem is support for multi button switches. Insteon has a 6 button and an 8 button switch and several remote multi button controllers. I use a few of the 8 button switches throughout my home; they are wonderful except when Premise is involved. Each button on an 6/8 button switch can be cross linked to one or more Insteon switches. This allows me to turn on the outside entry light from the master suite when I go to bed for my daughter who arrives home late on occasion. I can turn off the kitchen light which always seems to be left on without leaving the bedroom. I can quickly see the status of up to 8 attached loads from a single 8 button switch.
Currently there is limited support for multi button switches. You cannot add the individual buttons as ConnectedDevices as you can with single button devices. However you can create group devices. When you go through the cross linking process using the buttons on the 6/8 button switch and another switch, a group is created under /Devices/CustomDevices/InsteonRoot/InsteonGroup_1. You can have up to 254 groups and add as many devices to this group as you want. Sending a PowerState=TRUE to the group device should turn on power to all members of the group, it doesn’t. It only works sometimes. If I have 4 devices in a group and send a PowerState=TRUE to the group, only some of the devices in the group respond. It is random as to which device/s will respond, and almost never the same twice. I have found that by spamming 3-5 PowerState=TRUE commands sequentially it almost always activates all members of the group, but I run the risk of hanging the driver when I do this.

I know this sounds like a network communications issue, however if I send a PowerState=TRUE to individual devices in the group they respond 100% of the time. If I send a PowerState=TRUE to the same 4 devices programmatically with no delays they work 100% of the time. Groups not so much.

Ok the reason groups are so important is that John built in a stealth mode for multi button switches that allows the local status lights to be updated but only when you use them as part of a group. Cross link button (2) and switch (A). Nothing shows in Premise, but if you send a PowerState=TRUE to InsteonGroup_1 button (2)’s status light, lights up showing the load is powered on. Of course this only happens sometimes. Sending a PowerState=TRUE to switch (A) will not update the status light on the multi button switches. They can only be updated using groups.

All this is due to a lack of true support for cross linked devices. John is clear that the current drivers lacks this support and added a few patches in to hold people like me over until a time when this support could be added. Since it's been almost a year since I last saw John on the boards and my wife is about to kill me with lights not doing what they are supposed to, local status indicators showing a light is off when it is really on etc. I was hoping to contact John and ask about any updates he has done to the current driver, or barring that ask about getting a copy of the source. I have a friend who is a programmer and he offered to take a look at it. He doesn’t know anything about Premise so it’s a long shot. However the alternative is to scrape 50 Insteon devices and start over with another technology. Ick!

Kaz
 
Kaz,

Sorry for your troubles.

What is clear is that user-supported drivers will always have limitations. Whatever I've shared with the community is based on my needs. Eventually, someone may want a feature that I can't be bothered to support or its just too darn difficult to build or I simply don't have the time or motivation to provide assistance.

My answer to this problem is to offer up the source code and let someone else take over. It's not an easy decision because some drivers (notably my USB-UIRT driver) took a great deal of my time and effort. This investment makes one leery of sharing it with the world, for free, only to have it used for a commercial purpose that puts money in someone else's pocket. OK, that's probably not a high-probability with Premise but portions of the code could end up in a commercial product. You get the idea ...

I don't know what John's position is on this issue but he's a standup guy, it's his time and money, and it's his call. Such is the risk of using user-contributed software. For example, I used Rob Brun's SYSTapi application for awhile until one day it refused to recognize my voice modem. Why? Don't know, but I'd love to look at its source code and fix whatever is ailing it. I contacted Rob but he cannot locate the source code. Such is life.
 
Back
Top