Browsed by
Category: Home Automation

Posts that broadly concern the topic of Home Automation, including hardware and software issues.

strong-lock-locked-padlock-39624 by topten5 is licensed under CC BY 2.0
Mosquitto SSL/TLS Error SSL routines:ssl3_get_record:wrong version number

Mosquitto SSL/TLS Error SSL routines:ssl3_get_record:wrong version number

Up front, I will admit that I ran into this error because I did not read the documentation fully. However, in my defense, I feel like the error reporting could be clearer and the imprecise error message caused me to waste a bunch of time looking in the wrong place. Hopefully, this will prevent someone else from wasting their time as well.

Using an SSL/TLS Connection with Mosquitto MQTT

This is not a post about how to setup SSL/TLS on a Mosquitto broker. That has been well covered. Personally I followed the Mosquitto docs for instructions generating the necessary certificates and keys. Since I am using the Home Assistant Mosquitto Add-On I followed it’s instructions for configuring the Mosquitto Broker.

However, when I tried to connect using the mosquitto_sub command line tool, all I got was this:

 Client mosq-WzCVS53wMuaPbU8oNT sending CONNECT
 Client mosq-WzCVS53wMuaPbU8oNT sending CONNECT
 Client mosq-WzCVS53wMuaPbU8oNT sending CONNECT

When I checked the logs of the Mosquitto broker, all I saw was this error

Client connection from XXX.XXX.XXX.XXX failed: error:1408F10B:SSL routines:ssl3_get_record:wrong version number.

So I spent an hour trying different tls_versions and ciphers with no luck.

You must Specify a cafile or capath to Enable Encryption

It is that easy. If you specify the correct --cafile or a --capath in your mosquitto_sub command, things should work.

I would have expected a better error message from the broker or the client. I also was under the impression that using the --insecure flag would have allowed testing without the --cafile. I was wrong.

Of course, in hindsight the documentation clearly notes this requirement.

mosquitto_sub man page excerpt.
Yup, that is pretty clear.

Insteon is Great; The User Experience is Awful

Insteon is Great; The User Experience is Awful

I own more than 75 Insteon products. I also own numerous other “smart” devices from other manufacturers.  In all I have video doorbells, smart smoke detectors, controlled door locks, weather stations, electronic blinds, smart light switches in every room, smart outlets, and a sophisticated automation hub to link all of this together.

Beyond that, I have been involved in open source programming for home automation for a number of years.  I have contributed extensively to Misterhouse, written some of my own Insteon software, and most recently started contributing to an Insteon-MQTT project for Home Assistant.  Over the years I have spent hours digging into and deciphering the Insteon messaging protocol and solved some very complex problems.

In short, I should be the target audience for anything related to home automation/ internet of things (“IOT”).  Given my work and usage of the products I speak also with some authority about issues related to Insteon.

With that out of the way, it is my opinion that historically Insteon products are good (not great) and that the Insteon user experience is awful.

This opinion is formed from years of irritation with Insteon and Smart Labs, but my recent experience with the Insteon Hub is the impetus for this entry.

Insteon Hardware

Insteon hardware has had its issues, many of them fail to last largely due to electronics issues.

  • 2008 – Cheap tactile switches were used in Insteon products causing what seems like all of the devices to stop working.  As the sad owner of many of these devices this was very irritating.
  • Constant – Bad capacitors used in PLMs this has been a problem at least as far back as 2014 and appears to continue today. I recently had to have a PLM replaced due to this issue.
  • Currently – Possibly more bad capacitors used in Hubs I honestly don’t know why power supply capacitors continue to be an issue.  Again, I also have suffered through this failure.

That said, in generally I find the hardware to be largely acceptable, as long as it doesn’t break.  The prices are reasonable, the appearance is generally acceptable, and the mechanical components stand up to a fair amount of use without breaking.

If the electronics were more robust I would fully endorse the hardware.

Insteon Software

Sadly things go dramatically downhill on the software side.  I won’t get into the poor choices buried deep inside the Insteon protocol (ahem, not a stateless protocol), but needless to say there are many.  I also won’t go into detail about the poor and inaccurate documentation.  While these things are bad and should have never happened, these are only problems that developers see.

However, Smart Labs and Insteon have continually released poor consumer facing software.  For example HouseLinc, is a windows automation app offered by Insteon.  It looks like something written for Windows 95 (indeed it supports XP through Win 7).  Even ignoring that, it had extremely limited functionality and offers no web based or mobile phone control.

The current Insteon Hub is no better. In the 5 years since its release. Insteon has release two separate mobile applications for it App One and App Two. Neither app is very user friendly. As I noted above, some of the Hubs died prematurely. When this happened, there was no way for a user to migrate to a new hub, or even to sign into their account to add a new Hub! The only option was to use a different email address to create a new account, or call Insteon and ask them to do some magic.

Insteon is Hostile to Developers, or at least Apathetic

Years ago, Insteon had a paywall for developers. It was something like pay a $200 one time fee and they would give you access to their developer documents for their devices. The sad thing, was that these documents were poorly written, often failed to disclose all of the features, rarely updated, and contained numerous errors.

Luckily, by using various tricks, many of us have been able to “sniff” the Insteon traffic and have reverse engineered support for features through a lot of hard work.

Today, Insteon claims to accept developer applications, but I have never heard of anyone hearing back from them.

I suspect that the makers of the ISY products have developer access and possibly a contact at Insteon that will answer their questions. Of course, ISY sells its products through Insteon and SmartHome. I suppose it is possible that Insteon is reluctant to help any other developers as a favor to ISY.

I am Still an Insteon Advocate

Given all of my complaints, you should rightly expect that I would have abandoned Insteon years ago.

But I still believe that fundamentally, their products are some of the best home automation products you can buy.

Why?

  1. The products do not require or use any cloud based service.*
    • This means there are no outages.
    • Insteon devices will continue to work even if the company goes out of business. This isn’t true for other protocols.
  2. The products use both radio frequency and power line communications.
    • Given a decent sized network, they tend to suffer from less communication issues than competing products.
  3. They do not use wifi!
    • The joke as long been that the “S” in IOT stands for security.
    • Keeping my devices off of the network makes them a much less tempting target for hacking.
  4. The products generally look nice and work well.
    • Honestly, this should be your main concern when buying any home automation products.
  5. The protocol had remained consistent for 20+ years.
    • Devices purchased 20 years ago are still compatible with devices purchased today.

* The Insteon Hub does have a cloud component, and can suffer at least partial outages in the app. But my understanding is that even when the cloud is down, local control using the hub still continues to work.

What Insteon Needs to do Going Forward

  1. Embrace Developers!
    • The Home Automation community is dominated by Makers and Hobbyists.
    • Sure, some users only want their Google Home Device to be able to turn on their lights. But in my experience, once a user does this, the majority of them start looking for more complex home automation systems.
  2. Stop trying to be Google.
    • By this I mean, embrace your local control. Forget or at least minimize the cloud.
    • You can sell this as a privacy and security feature, because it is!
  3. Fix your software!
    • The user experience is critical.
    • You have to get the basics to work smoothly first.
    • If that means you have to temporary abandon some cloud features, then do it.
    • If you do step 1, the community will make a great user experience for you.

These are my initial thoughts. I will try to revisit this post as I more thoughts come to me.

Technical Inspection of Insteon Hub2 2245-222

Technical Inspection of Insteon Hub2 2245-222

The following are some notes I gathered while investigating the technical possibilities of the Insteon Hub2.

Starting Nmap 6.40 ( http://nmap.org )
Nmap scan report for 192.168.XXX.XXX
Host is up (0.00058s latency).
Not shown: 65535 open|filtered ports, 65531 filtered ports
PORT STATE SERVICE
23/tcp open telnet
443/tcp open https
992/tcp open telnets
25105/tcp open unknown
MAC Address: 00:0E:XX:XX:XX:XX (Smarthome)

Nmap done: 1 IP address (1 host up) scanned in 2306.43 seconds

I can connect to both telnet ports, but all I get is a blank screen that doesn’t seem to respond to any commands.  It also doesn’t seem to broadcast the buffer contents.

After a lot of futzing, I was able to connect to the https 443 port.  It uses the deprecated RC4-MD5 cipher and a self-signed certificate.  You will also need to use Basic Auth and the username and password.  Once in, the webpage looked identical to the one described below, I was unable to determine any other benefits of this port.

The 25105 port is configurable.  It is a basic http port that requires Basic Auth using the username and password printed on the bottom of your hub.  The default webpage is very basic, with a link to http://connect.insteon.com and the product manual and support pages.

There is some rudimentary available at this port.  It is rather crudely documents (as is Insteon’s style) here: http://cache.insteon.com/developer/2242-222dev-062013-en.pdf.  See pages 6-10.  Note that this document is actually for the Hub1, I have yet to find any developer notes for the Hub2.

The buffstatus.xml page provides access to the incoming messages for the Hub2.  Of note, the Hub2 has a 200 character buffer not the 100 listed for the 2242-222.  Also, undocumented is the final two characters of the buffer.  These turn out to be a hexadecimal representation of the last position written to.  Essentially, the incoming messages are written left to right and when the 200th position is reached it goes back to 1.  The characters are never cleared (unless you call a special command to do so) but are merely overwritten.

It is possible to poll the Hub2 about twice a second and to use the buffer to see all of the messages received by the Hub2.  This seems to work rather reliably, and the constant polling doesn’t seem to upset the device.

I am not aware of a way to see outgoing messages.

The interface also allows for sending of some messages.  See the http://xxx.xxx.xxx.xxx:25105/3?YYYYY=I=3 documentation in the above pdf.  This seems to provide an interface to communicate with devices from the hub.   However, as of yet, I am not able to communicate much if at all with the hub using this interface.  As a result, I am unable to scan the hub’s link table.  Update: Figured it out.  So far all of the common PLM commands seem to work with the 3?<CMD STR>=I=3 style message.  But, anytime a 3?<CMD STR>=I=3 style message is sent, the buffer is zeroed out and the buffer position is reset to 00.

Finally, I took a TCPDump of the Hub2.  Best I can tell, the Hub2 doesn’t open any outside ports on my router.  This is contrary to the claim that it does “automatic port forwarding.”  This is probably for the best security-wise anyways.

Instead it appears that the Hub creates a persistent connection to insteon.pubhub.com (hosted on Amazon Ec2).  Poking around http://www.pubhub.com confirms this.  The communication is all SSL encrypted.  I thought about placing a man-in-the-middle and trying to decode this messaging, but I doubt it would be much help.

A Temperature Controlled Whole House Fan with MisterHouse

A Temperature Controlled Whole House Fan with MisterHouse

MisterHouse Web Interface for a Temperature Controlled Whole House FanThe main feature of MisterHouse that sets it apart from other home automation systems is the ability to customize practically every aspect of the system.  The following example is a perfect demonstration of this.

I recently purchased a whole house fan, basically a giant fan that sucks hot air out from the highest point in my house. They are great if you live in a climate with cool nights.

The controls for my fan were very basic, an on/off switch and a two-speed setting.

With Misterhouse, I created an “auto” mode which will only turn on the fan if both the indoor temperature is above a defined threshold and the outdoor temperature is 5 degrees below the indoor temperature.

This is how I did it.

Starting Materials
– A Whole House Fan
– 2 IOLincs, (1 for on/off, 1 for fan speed)
– A MisterHouse enabled indoor temperature sensor (I used my Insteon Thermostat)
– A MisterHouse enabled outdoor temperature sensor (I used data from a neighbor’s weather station through weatherunderground)

I created the following items in my mht file:

GENERIC, house_fan, HVAC|WHF_Group
GENERIC, house_fan_temp, HVAC|WHF_Group
GENERIC, house_fan_setpoint, HVAC|WHF_Group
GENERIC, house_fan_ambient, HVAC|WHF_Group
INSTEON_IOLINC, DE.AD.BE:01, whf_main, HVAC
INSTEON_IOLINC, DE.AD.BE:01, whf_speed, HVAC

I also had the following items already setup:

$upstairs_thermo_temp #the temperature upstairs
$w_temp #the outside temperature

First, I set the available states for my generic objects:

$house_fan-&gt;set_states('on', 'off', 'auto');
$house_fan_speed-&gt;set_states('high', 'low');
$house_fan_temp-&gt;set_states('cooler', 'warmer');

Then I tied my generic items to my Insteon Devices:

$house_fan-&gt;tie_event('$whf_main-&gt;set("on")', "on");
$house_fan-&gt;tie_event('$whf_main-&gt;set("off")', "off");
$house_fan_speed-&gt;tie_event('$whf_speed-&gt;set("on")', "high");
$house_fan_speed-&gt;tie_event('$whf_speed-&gt;set("off")', "low");

Then I tied my Generic temp item to my Generic setpoint item, and inserted some custom code:

$house_fan_temp-&gt;tie_event('house_fan_temp_change($state)');
sub house_fan_temp_change {
	my ($state) = @_;
	if ($state eq "warmer"){
		$house_fan_setpoint-&gt;set(int($house_fan_setpoint-&gt;state) + 1);
	} elsif ($state eq "cooler") {
		$house_fan_setpoint-&gt;set(int($house_fan_setpoint-&gt;state) - 1);
	}
}

By doing this, I can have a nice cooler and warmer button in the web panel.

Finally, every minute I check to see if the device is in “auto” mode and whether or not it should turn on:

if ($New_Minute){ 
	if($house_fan-&gt;state eq 'auto') {
		if (int($upstairs_thermo_temp-&gt;state) &gt; int($house_fan_setpoint-&gt;state) &amp;&amp;
		(int($upstairs_thermo_temp-&gt;state) - 5) &gt; int($w_temp-&gt;state)) {
			if ($whf_main-&gt;state eq 'off') {
				::print_log("[a1housefan.pl] Auto: Turning on fan");
				$whf_main-&gt;set("on");
			}
		} else {
			if ($whf_main-&gt;state eq 'on'){
				::print_log("[a1housefan.pl] Auto: Turning off fan");
				$whf_main-&gt;set("off");
			}
		}
	}
}

The result, is a temperature controlled whole house fan.  The image above is a screen shot from my web interface.

Insteon RemoteLinc 2 Lacks the Heartbeat Feature?

Insteon RemoteLinc 2 Lacks the Heartbeat Feature?

A heartbeat is a simple broadcast packet sent at a predetermined interval.  The purpose of the packet is to announce to everyone that the device “is still alive.”

The Insteon RemoteLinc 2 is a battery powered insteon remote, that remains in a sleep state when it is not sending messages.  In this state the remote does not listen or respond to any packets sent to it.

As a battery operated device, the remotelinc will eventually need to be recharged, and it would be nice to know when a recharge is needed rather than finding out when the device doesn’t work.  The remotelinc has a command to query the battery level, but this query won’t work if the device is asleep.

This is where a heartbeat message would be nice.  It would automatically wake up the device at a periodic interval, allowing a battery level request to be sent to the device.

Best I can tell, the Remotelinc heartbeat function has been disabled or not included.  The following settings are supposed to control the hearbeat function:

Awake Interval Sets the amount of time the Remotelinc remains awake with no activity. This is editable
Sleep Interval Sets the amount of time the Remotelinc remains asleep, before waking up to send a heartbeat message. The device ACKs my changes, but the settings on the device don’t change.
Broadcast Number Sets the number of heartbeat messages that should be sent every time the sleep interval expires. The device ACKs my changes, but the settings on the device don’t change.
NoIAmAwake Bit A single bit to disable sending heart beat messages, presumably overrides all of the other settings. The device ACKs my changes, but the settings on the device don’t change.

Other users have reported similar problems over at the Indigo support forum.

As a work around, Misterhouse will send a battery level request immediately after receiving a message from the RemoteLinc.  The RemoteLinc will stay awake after sending a message for the amount of time specified in Awake Interval, I set mine to 10 seconds. Battery level requests will only be sent if the amount of time since the last battery level response has exceeded a defined threshold.

All of this works well, except for rarely used devices.  It is possible that such a remotelinc could die without there being a chance to query its battery level.