Insteon PLM - bad data received: got unknown command code 0x06

Got a new PLM and that doesn’t seem to be the problem.

Things I have tried (multiple times)

  • New PLM
  • New PLM to serial cable
  • 2 different USB to serial adapters
  • Multiple different USB ports
  • 2 Different PCs
  • Plugging PLMs in in 3 different locations (different circuits in the house)
  • New install of OH2 snapshot with only the InsteonPLM binding installed and configured vs previous installation of OH2 release version and differnet versions of InsteonPLM binding
  • Air-gapped all devices in my house except 3 fanlincs 3 hidden door sensors and 1 thermostat
  • Combinations of all of the above

Every time I get this:

2017-06-03 10:44:45 org.openhab.binding.insteonplm.InsteonPLMActiveBinding.processBindingConfiguration(InsteonPLMActiveBinding.java:319) - dead device timeout set to 3000s
2017-06-03 10:44:45 org.openhab.binding.insteonplm.InsteonPLMActiveBinding.updated(InsteonPLMActiveBinding.java:273) - configuration update complete!
2017-06-03 10:44:45 org.openhab.binding.insteonplm.InsteonPLMActiveBinding.initialize(InsteonPLMActiveBinding.java:358) - initializing...
2017-06-03 10:44:45 org.openhab.binding.insteonplm.InsteonPLMActiveBinding.initialize(InsteonPLMActiveBinding.java:370) - config: poll_interval -> 300000
2017-06-03 10:44:45 org.openhab.binding.insteonplm.InsteonPLMActiveBinding.initialize(InsteonPLMActiveBinding.java:370) - config: port_0 -> COM9
2017-06-03 10:44:45 org.openhab.binding.insteonplm.internal.driver.Driver.addPort(Driver.java:83) - added new port: port_0 COM9
2017-06-03 10:44:45 org.openhab.binding.insteonplm.InsteonPLMActiveBinding.initialize(InsteonPLMActiveBinding.java:370) - config: more_features -> C:\openHAB2\addons\insteonplm\more_features.xml
2017-06-03 10:44:45 org.openhab.binding.insteonplm.InsteonPLMActiveBinding.initialize(InsteonPLMActiveBinding.java:370) - config: refresh -> 600000
2017-06-03 10:44:45 org.openhab.binding.insteonplm.InsteonPLMActiveBinding.initialize(InsteonPLMActiveBinding.java:370) - config: more_devices -> C:\openHAB2\addons\insteonplm\more_devices.xml
2017-06-03 10:44:45 org.openhab.binding.insteonplm.InsteonPLMActiveBinding.initialize(InsteonPLMActiveBinding.java:370) - config: service.pid -> org.openhab.insteonplm
2017-06-03 10:44:45 org.openhab.binding.insteonplm.InsteonPLMActiveBinding.initialize(InsteonPLMActiveBinding.java:376) - setting driver listener
2017-06-03 10:44:45 org.openhab.binding.insteonplm.InsteonPLMActiveBinding.initialize(InsteonPLMActiveBinding.java:378) - starting 0 ports
2017-06-03 10:44:45 org.openhab.binding.insteonplm.internal.driver.Port.start(Port.java:149) - starting port COM9
2017-06-03 10:44:45 org.openhab.binding.insteonplm.InsteonPLMActiveBinding.logDeviceStatistics(InsteonPLMActiveBinding.java:684) - devices:   0 configured,   0 polling, msgs received:     0
2017-06-03 10:44:45 org.openhab.binding.insteonplm.internal.driver.Poller$PollQueueReader.run(Poller.java:188) - starting poll thread.
2017-06-03 10:44:50 org.openhab.binding.insteonplm.internal.driver.SerialIOStream.open(SerialIOStream.java:58) - setting port speed to 19200
2017-06-03 10:44:50 org.openhab.binding.insteonplm.internal.driver.SerialIOStream.open(SerialIOStream.java:65) - successfully opened port COM9
2017-06-03 10:44:50 org.openhab.binding.insteonplm.internal.device.ModemDBBuilder.start(ModemDBBuilder.java:51) - querying port for first link record
2017-06-03 10:44:50 org.openhab.binding.insteonplm.InsteonPLMActiveBinding.initialize(InsteonPLMActiveBinding.java:380) - ports started
2017-06-03 10:44:50 org.openhab.binding.insteonplm.InsteonPLMActiveBinding.initialize(InsteonPLMActiveBinding.java:386) - initialization complete, found 1 port!
2017-06-03 10:44:50 org.openhab.binding.insteonplm.internal.driver.Port.clearModemDB(Port.java:139) - clearing modem db!
2017-06-03 10:44:50 org.openhab.binding.insteonplm.internal.driver.Port$IOStreamWriter.run(Port.java:406) - starting writer...
2017-06-03 10:44:50 org.openhab.binding.insteonplm.internal.driver.Port$IOStreamWriter.run(Port.java:415) - writing (0): OUT:Cmd:0x60|
2017-06-03 10:44:50 org.openhab.binding.insteonplm.internal.driver.Port$IOStreamReader.run(Port.java:268) - starting reader...
2017-06-03 10:46:50 org.openhab.binding.insteonplm.internal.device.ModemDBBuilder.run(ModemDBBuilder.java:76) - modem database download unsuccessful, restarting!
2017-06-03 10:46:50 org.openhab.binding.insteonplm.internal.driver.Port.clearModemDB(Port.java:139) - clearing modem db!
2017-06-03 10:48:50 org.openhab.binding.insteonplm.internal.device.ModemDBBuilder.run(ModemDBBuilder.java:76) - modem database download unsuccessful, restarting!
2017-06-03 10:48:50 org.openhab.binding.insteonplm.internal.driver.Port.clearModemDB(Port.java:139) - clearing modem db!

I am totally out of ideas, if I had any alternative I would give up :disappointed: :disappointed:

At this point I would try a rain dance or voodoo dolls or anything really - please help!

1 Like

I can only think of two things to try:

Install Insteon-terminal and see if you can connect tot the plm and download database.

Maybe better than that, try installing openHAB 1. The Insteon-plm binding is really a oh1 binding and the developer/maintainer is running oh1. Especially since you are running an OH2 snapshot, who knows the stability of the bleeding edge. I don’t think there are many people running OH2 with Insteon.

The insteon terminal is definitely the lowest common denominator. It’s not that hard to install on ubuntu, but I cannot support it on Windows (which you seem to be running).

It works!

It looks like the problem was a faulty USB hub, that is only faulty when used with the PLM, as far as I can see.
However I was even more confused as I was getting the same problem on a different PC without the USB hub. I can’t figure out what is wrong there, but I’m pretty sure this is not a software issue! Hooray!

Through all my troubleshooting and trying different combinations of things I somehow encountered the two unrelated USB issues that sent me off on the wrong track.

Anyway, @Bernd_Pfrommer thank you for sticking with me through this!

I have a related question that I can spin off into a new thread if you think it is relevant as I’m not sure if my current situation is ‘normal’: I see a lot of traffic on my network even when the house is quiet and no devices are being triggered. I set my poll interval to 1h poll_interval=3600000 to see if the traffic would die down but I am seeing constant messages in the log at least every 30 seconds.
My refresh is still set at 1m refresh=600000 however.

I have approx 65 devices and I see from the notes in the config file that a poll interval of 5m is recommended for approx 110 devices so my question is, should I see constant traffic on the network? Approx how long should a poll or a refresh take per device?

Awesome!

On the poll question, I’d guess that is probably normal. If you have 65 devices, each polling once an hour (in series) you’d have to pull more than every minute to get through each. Add in some lag time, and possibly having more than one item per device and you probably have polls every few seconds.

Ah, Is that how it works? Poll time/number of devices ~= time between each poll?
That makes sense if it is.

So with 65 devices that would mean a poll every ~4.5 seconds if the poll interval was set to 5m (I think).
So there would be traffic almost constantly (not that that is necessarily bad). Do you have any idea how long it should take to poll a device and get a response?

Also, I have a few complicated devices like a thermostat, and some less complicated like fanlincs and an I/O linc and quite a few (10 i think) keypads all in 8 button mode. …and I have all of the features of all devices broken out as individual items, (inc. FastOnOff, ManualChange, even for each button of each keypad). Does the binding poll for each feature or just each device?

At some point I would think that if there are too many messages then it will cause others to get lost, causing additional messages, etc, etc. (I know there is a limit on the hops to avoid a cascade).

Tom got it right. Adding to this: most devices can be polled by a single query/response exchange, but sometimes multiple queries are necessary to get all features polled, i.e the LED brightness might require one query, the status of the buttons another. The binding does consolidate the querying though, and if the status of multiple features is delivered in a single packet, it will only query once.
You are right in assuming that increased traffic is bad. The more traffic, the more messages are lost, so only instantiate features when you are actually using them, because they may trigger additional querying.

Thanks @tommycw10 and @Bernd_Pfrommer so just to make sure I got it straight:

Poll time/number of devices ~= time between each poll where ‘number of devices’ = number of physical devices regardless of features defined as items, except:

  • LED brightness (possibly) and would account for +1 poll per supported device
  • Possibly other complicated devices that require multiple queries to get all data

Did I get that right?
If so, since I don’t have LED brightness enabled (yet), but do have pretty much all other features as items on all ~65 devices, and I have only 1 thermostat, 10 8-button keypads, 3 door sensors, 1 synchrolinc, 3 fanlincs, 1 I/O linc and the rest dimmers and switches then I probably have ~70-75 polls per interval?

In the right ballpark. You can switch on the debug log and see what is
being queried.

@Bernd_Pfrommer

After the recent addition of the LED Brightness - I added openhab items for LEDBrightness for all of my devices and, I’ve noticed more lag in my system. Was assuming it is a polling/traffic issue, but haven’t played around with it at all yet. Was wondering if there is a way to turnoff polling on a per item basis? With LED Brightnesses, I really don’t need their status to be updated via poll, only shoot out commands every once and a while, but I think just having the item defined makes it get polled correct?

That is correct.

You may be able to hack that with a custom device_types.xml file. Usually the advanced features are nested inside a feature_group, and all features within this feature group are polled with a single message (in this case an extended status query):

<feature_group name="ext_group" type="ExtStatusGroup">
      <feature name="ledbrightness">LEDBrightness</feature>
	  <feature name="ramprate">RampRate</feature>
 </feature_group>

Since the enclosing feature_group is responsible for querying, you may be able to avoid the polling by adding a free-standing feature outside the feature group:

<feature name="ledbrightness_nopoll">LEDBrightness</feature>

This should give you the command functionality without the polling.