Help with specialty Insteon switches showing up as Thermostats

I have two of thse SmartSense fans:

The are basically just regular bathroom fans but with an insteon switch. The switch model is SMSC110.
As far as I can tell the insteon switches are just regular switches with added programming to appoint a master and slaves and program the group to kick in based on self computed intervals. Really cool stuff although you could probably accomplish something similar in vera. But I digress…

My issue is that once I pair them in vera with the PLM they show up as thermostats, not switches.
The documentation states that they can be connected with a controller.
Obviously as “thermostats” vera complains that it cannot figure out the status of the devices.

After my little time so far with vera all I could figure is that I probably need to change the device file to a switch. Question is - which file is the right one? D_BinaryLight1.xml or something else?
and do I need to set anything else?

I will poke at it regardless but was hoping for some advice

According to the developer documents, the Broan devices will report that they are DevCat 05. With the exception of the Broan devices, DevCat 05 is used for thermostats. It is likely that the Vera code sees the DevCat 05 device and just assumes that it is a thermostat.

That said, if all you want to be able to do is turn it on and off, then changing it to D_BinaryLight may work. The commands for on and off are the same for all devices, so as long as you can find a way to convince the Vera that the device is an on/off switch you should be good to go. That said, I am not sure I would hold my breath. I would guess that the Vera would tend to believe what the device tells it over what the person at the keyboard does. And, where the on/off commands aren’t really used in the thermostats, I would imagine there is little to no implementation available.

I played with the settings but vera always changes it back to a thermostat. I even tried adding it as a new device but after vera reaches out to the switch, it gets changed to a thermostat.
If I go with your app, and I set it up as a switch, would it keep the settings?

Altsteon would probably let you change it to something other than a thermostat, but it probably won’t work. Since the on/off command doesn’t do anything for thermostats, and I couldn’t find anywhere to purchase the Broan device for testing, I didn’t implement it.

That said, I would be happy to implement it. Are there any special functions that the device has? Or is it primarily just an on/off switch? I probably won’t have time to do anything for about two weeks as I am buried at work, and will be at Google I/O next week. But, the following week I can probably get it in. It shouldn’t be too hard.

If I can find a few hours free I will be all over Alsteon and let you know how it works. Maybe tomorrow or by the weekend.
They have some programming options that are documented in the manual (for example turn off automatically after 60 minutes etc.). But in the end they are just switches. Just on and off.

I have a better idea - I go to Google i/or in your place and you spend the time I freed up so graciously for you to program the switches…

I always appreciate people that are willing to “take one for the team”. A couple of years ago I had to “take one for the team” when I was “forced” to upgrade to business class on a flight from London to New York. It was hard, but someone has to think of the children. ;D

It is possible that I will find a few minutes here and there and get it done sooner. But, I figure if I set expectations low enough, I end up looking really good when I get it done early. :slight_smile:

Did the manual include the byte codes to control the different features? I’d love to have a complete implementation if possible.

Makes me think of the time my dad’s flight was overbooked from London to new york and he was “forced” to fly on a Concord instead and get there in half the time.
Nothing in the manual. Barely a mention of insteon. But I will see if Google knows more.

Just a quick update as FYI;
I got Alsteon up and running. And then tried adding the fan controllers as relay switches but no go. Vera can not get the status or turn the device on/off.

Glad to hear you got it installed. It shouldn’t take much to get some support in a dev version. I’ll see if I can get something done in the next few days.

Okay, it was more than a few days. Holidays and work slowed me down a bit.

I have not implemented the UI pieces yet, as I wanted to know that the code was working before I put any effort in to that. So, you will need to test the daemon manually to make sure it works and then report back. You can download a dev version from http://www.geektaco.info/altsteon-broan.tar.gz .

NOTE : You probably only want to use the daemon. Loading the XML files on may cause issues as I still have them in a somewhat broken state while I work on the ser2net pieces.

To manually test, fire up the daemon, then fire up the altsteon_cli program. At the cli prompt, enter the command “add_device aa.bb.cc” where aa.bb.cc is the address of the Broan device that you have. During the next few seconds you should get some basic information back about the device. (The DevCat and SubCat, Insteon level, etc.) Once the cli has gone quiet, you can use the commands “aa.bb.cc on” and “aa.bb.cc off” to control your devices. After you send that command, you should get a result code back that ends with a string indicating that aa.bb.cc is on or off. If all of that works, then it should be a matter of getting the XML files in place to get the switches to be controlled via the UI. (If you are feeling adventurous you could probably get the XML files working by copying the relay files, renaming them, tweaking them a little, and then adding the necessary LUA code to I_InsteonPlm.xml.

If the switches don’t work, then it would help for me to get debug output from the daemon. The easiest way to do that is to open two ssh sessions. In one of them, run altsteon with the “-ddd -f” flags, and have the ssh client capture all of the output to a log file. Then, in a second ssh session, enter the commands I outlined above. On the session that is running the daemon, you should see lots of hex scroll by along with a bunch of other status messages about what is going on. Once you run the last command from above, wait ~10 seconds to make sure all of the output is gathered, then you can CTRL-C out of the daemon, and save off the log file. There shouldn’t be anything sensitive in the log file, so you can attach it to your response. Or, if you would feel more comfortable you can PM the log file to me directly.

Thx fba, I’m finally getting around to installing this.

Quick clarification: I get to “aa.bb.cc on” and get the error "Unknown command ‘on’. "

swazi -

Sorry for disappearing. Work got a little out of hand for a while. :wink:

If you run the command “aa.bb.cc info”, what do you get back? (Making sure that aa.bb.cc is the address of your Broan device.)

Here is the output from one of my switches :

Cmd : 16.67.68 info 16.67.68:0007,02,02,1C - DevCat : 02 SubCat : 1C

Your output should say DevCat : 05, the SubCat value is important. In the code, subcats 00, 02, 05, and 06 are listed as “non-thermostat” devices. If your device shows up with a subcat other than one of those four, then the code won’t let you execute the “on” or “off” commands. I am wondering if the developer documentation is incomplete on what all of the sub-categories are. It wouldn’t be the first time that the developer docs were wrong. :wink:

Sorry too - I was on vacation. Not as exciting as working but we all have to do what we have to do right?
In any case - the topic on hand. Both DevCat & SubCat come back as “FF” which I assume is bad. Below is the copy/paste:

Cmd : add_device 17.B4.CF
17.B4.CF:001C,02,00 - Insteon version 0.

Cmd : 17.B4.CF info
17.B4.CF:0007,02,FF,FF - DevCat : FF SubCat : FF

Interesting. Altsteon is communicating with the device, which you can tell from the line that indicates the device is using version 0 of the Insteon protocol. (There are three versions of Insteon in the wild. They will return values of 0, 1, and 2, but are called i1, i2, and i2cs respectively.) However, when we probe the device to determine what it is it doesn’t seem to be answering.

Not having that information isn’t necessarily “bad”, but it is problematic. Altsteon uses the devcat and subcat values to know what commands should be possible to use on a device. It Altsteon can’t poll the information from the device, then you will need to manually push it. (You have to do this with battery powered devices like the motion sensor and triggerlinc.)

According to the table of Insteon devices, there are two Broan models that exist. The SMSC080 and the SMSC110. The subcats for those are 0x00 and 0x02 respectively. Since on and off seem to be the only commands that will work with these devices, it shouldn’t matter if you get the subcat right. You should be able to use either of them. Though, if later I find additional commands that only work on one or the other and you have the wrong subcat, your may see some lag talking to the device while Altsteon times out sending a command that isn’t valid. So, if you know the model you have, use the correct subcat. If you don’t, then just guess.

To force a devcat and subcat setting on a device, you just add the devcat and subcat to the end of your add_device command. So, you would use :

add_device 17.b4.cf,05,00

If you have the SMSC080. Then, wait a minute or so, and try sending an on or off command.

17.b4.cf on

Assuming everything worked correctly, your fan should turn on or off.

When you move that over to UI5, you basically use “17.b4.cf,05,00” as the address. That string is sent directly to the add_device command.

If it still doesn’t work, then verify that the “17.b4.cf info” command returns the devcat and subcat you expect. If not, then we will need to dig in to debug logs to see what is going on.

No luck!

Cmd : add_device 17.b4.cf,05,02
17.b4.cf,05,02:001C,02,00 - Insteon version 0.

0F.88.F9:0049,01 - Sensor is active.

0F.88.F9:000A,01 - Contact is open.

Cmd : 17.b4.cf on
17.b4.cf:FFFE,02 - Unknown device ‘17.b4.cf’.

Cmd : 17.b4.cf info
17.b4.cf:FFFE,02 - Unknown device ‘17.b4.cf’.

The SMSC080 and SMSC110 relate to 80CFM and 110CFM fans respectively. According to the manual the two different fan models each have their own switch. I have the 110, so 02 for the subcat. I also tried 00 just to be redundant

Hmm… It would be useful to see a debug log of what is going on. Can you start the daemon with the -ddd -f options and record the output while you run those commands?

I’ll also see if I can find some time this weekend to see if I can figure out what is going on.