I’ve also created individual features for each input in \custom\my_features.xml and I know this is where the issue is. I am not 100% familiar as to how the commands operate. I was using the Simplehomenet program to communicate and find what the exact command was but still no luck on getting it to poll/control the device correctly. Any help will be much appreciated
I am thinking of trying to get this to work as well. Have you made any progress? I have noticed that there is no documentation showing how the features work. Hopefully someone can enlighten us. Perhaps if you posted your work so far we could work together.
I am trying to get the simple outputs of the device to respond first. I need to generate an Insteon message with byte one set to 45 to turn on and 46 to turn off. The second byte needs to be set to the output number. I am having trouble determining how the command handlers generate messages.
I have decided to try the generic contact feature to get an idea of how the features generate an insteon message so I set up a device as follows:
I have created a switch item and tested it hoping to see a message but I only get the following in the log:
2016-08-14 11:03:17 INFO o.o.b.i.InsteonPLMActiveBinding[:595]- modem database has 2 entries!
2016-08-14 11:03:17 DEBUG o.o.b.i.InsteonPLMActiveBinding[:600]- modem db entry: 24.1B.53
2016-08-14 11:03:17 DEBUG o.o.b.i.InsteonPLMActiveBinding[:600]- modem db entry: 1E.7F.62
2016-08-14 11:03:17 INFO o.o.b.i.InsteonPLMActiveBinding[:611]- device 24.1B.53 found in the modem database and the modem responds to groups [0x01].
2016-08-14 11:03:17 DEBUG o.o.b.i.internal.driver.Poller[:64]- start polling device 24.1B.53|GenericContact->GenericContact(1:1:3)
2016-08-14 11:03:45 INFO o.o.b.i.InsteonPLMActiveBinding[:125]- Item: Output1 got command ON
2016-08-14 11:03:45 DEBUG o.o.b.i.i.device.InsteonDevice[:168]- processing command ON features: 1
2016-08-14 11:03:56 INFO o.o.b.i.InsteonPLMActiveBinding[:125]- Item: Output1 got command OFF
2016-08-14 11:03:56 DEBUG o.o.b.i.i.device.InsteonDevice[:168]- processing command OFF features: 1
Is the binding not generating an Insteon message or does the log not show it?
I have persisted with this and have now got basic functionality of the output ports. There is no polling so the status of each ouput is unknown at startup. I am using the NumberCommandHandler to build the insteon message.
Number Output1 {insteonplm="24.1B.53:00.00.13#Output1"}
Number Output2 {insteonplm="24.1B.53:00.00.13#Output2"}
Number Output3 {insteonplm="24.1B.53:00.00.13#Output3"}
Number Output4 {insteonplm="24.1B.53:00.00.13#Output4"}
Number Output5 {insteonplm="24.1B.53:00.00.13#Output5"}
Number Output6 {insteonplm="24.1B.53:00.00.13#Output6"}
Number Output7 {insteonplm="24.1B.53:00.00.13#Output7"}
Number Output8 {insteonplm="24.1B.53:00.00.13#Output8"}
I have decided to let Persistence and Rules deal with keeping the outputs up to date.
I do have the analog inputs working ok. I had to set up two features for each input because the value is sent split up between two messages. Once the features get the messages I am using a rule to calculate the value.
One features sends: command1:0x2B|command2:0x4C this returns a value in command2 between 0-255
The next feature sends: command1:0x2B|command2:0x4D this returns a value in command2 between 0-3
To get the correct value, the message in the second feature is multiplied by 255 and added to the value in the first message.
This works fine, but the problem is that the responses have the same “command 1” so the feature seems to mix them up sometimes
I feel like more time between polling the features would help. Is there a way to increase quiettime?
I need some assistance here. Is this thread in the wrong category? Even just some opinions.
I am trying to cobble support for this together. Should I be writing new handlers? I have eclipse installed but I wanted to try to make the existing handlers work first.
I don’t quite understand how the modem and EZIO work together. Can we consider them just a single device on the insteon network?
command 0x4a is supposed to read sensor value. I think it can only return a single byte though. Have you tried that one?
Also, the device supports extended length messages for setting parameters. I would not be surprised if there was also a get implemented, but not documented. In situations like this I use the “insteon terminal” (search on github) to explore how the device responds to queries and commands.
Thanks for taking a look at this.Yes it is tricky to poll twice
I had not seen these, I will read through them.
Yes that is were I got the commands and yes I am using the peek command 0x2B. In the notes section of the command sheet it shows the analog data being at address 0x4C. I have a utillity suite that connects to the device, using this I was able to find that the two analog inputs use address 0x4C - 0x4F.
Yes they appear as a single device
This was the first thing I tried but I got no response with that command.
I noticed on some devices that they do not reply unless your PLM modem (the one attached to the PC) is listed as a controller in that devices’ database. The moment I link the device as a responder to the modem, it starts answering to queries.
Wonder how all this works with the PLM inbetween. You may want to use the insteon terminal to query the link database of the remote PLM.
Ok, I have figured out the java rxtx and have insteon terminal connected to my PLM. Here’s what I have in the init.py:
from console_commands import *
from keypad2487S import *
from thermostat2441TH import *
from modem2413U import *
from switch2477S import *
from dimmer2477D import *
from ledBulb2672 import *
#
# if you are using a hub, replace login and password below with your
# hub login and password. Note: this is not the email address and password to
# the insteon web site, but the login/password on the back of the hub
#
def connectToMyHub():
"""connects to my insteon hub modem at pre-defined address"""
connectToHub("insteonhub", 25105, 1000, "MyHubLogin", "MyHubPassword")
#If you are using a legacy hub (pre-2014 hub)
def connectToMyLegacyHub():
"""connects to my insteon hub modem at pre-defined address"""
connectToLegacyHub("insteonhub", 9761) # syntax is address, port (generally 9761)
def connectToMySerial():
"""connects to my modem on pre-defined serial port"""
connectToSerial("/dev/ttyUSB0")
#
# uncomment correct line, depending on if you have a PLM modem or a hub (or a legacy hub)
# to automatically connect on startup. You will also have to change the info in the corresponding connectToMy...() function
#
connectToMySerial()
#connectToMyHub()
#connectToMyLegacyHub()
#
# Now define the devices you want to work with. For a list of
# available devices, look at the source code in the "python" directory
#
#
# Example device definitions
# kp = Keypad2487S("office_keypad", "30.0d.9f")
# th = Thermostat2441TH("kitchen_thermostat", "32.f7.2c")
# modem = Modem2413U("test_modem", "23.9b.65")
# closetLight = Switch2477S("closetLight", "25.65.d6")
# dimmer = Dimmer2477D("dining_room_dinner", "20.ab.26")
# ledBulb = LEDBulb2672("ledBulb", "21.EB.DD");
So do I need to write a device file now? Where should I start?
There is no way to send a custom message, specifying byte-by-byte. The way this was meant to work was like this:
In your init.py, instantiate a device that is close to what you have.
Unfortunately, your device is really an odd ball. I suggest you instantiate a Thermostat because that’s one of the most complicated devices out there, and lots of messages and handlers are already implemented.
(obviously change the address to match your ezio thingy)
This should get you some idea of what commands you can send:
help(th)
Try sending it some commands, see what happens.
th.getOpFlagsExt()
Have a look at the thermostat code in the python subdirectory (and the base classes thereof), and just hack it (like change the command codes etc).
Also see if you can read the link database with th.getdb(). Wonder what it replies in that case. Should be the remote PLM answering.
I never bothered implementing an interface to send raw bytes because for the extended messages you need a checksum, and that’s just not practical to compute by hand.
I have not had any time to do any exploring with Insteon terminal but I have found that since I installed it Openhab PLM no longer gets responses from any polls.
INFO o.o.b.i.InsteonPLMActiveBinding[:296]- read additional device definitions from /etc/openhab/more_devices.xml
2016-09-13 15:54:50 INFO o.o.b.i.InsteonPLMActiveBinding[:309]- reading additional feature templates from /etc/openhab/my_own_features.xml
2016-09-13 15:54:50 INFO o.o.b.i.InsteonPLMActiveBinding[:313]- dead device timeout set to 420s
2016-09-13 15:54:50 DEBUG o.o.b.i.InsteonPLMActiveBinding[:269]- configuration update complete!
2016-09-13 15:54:50 DEBUG o.o.b.i.InsteonPLMActiveBinding[:352]- initializing...
2016-09-13 15:54:50 INFO o.o.b.i.InsteonPLMActiveBinding[:364]- config: poll_interval -> 42000
2016-09-13 15:54:50 INFO o.o.b.i.InsteonPLMActiveBinding[:364]- config: port_0 -> /dev/ttyUSB0
2016-09-13 15:54:50 INFO o.o.b.i.InsteonPLMActiveBinding[:670]- devices: 0 configured, 0 polling, msgs received: 0
2016-09-13 15:54:50 DEBUG o.o.b.i.internal.driver.Driver[:75]- added new port: port_0 /dev/ttyUSB0
2016-09-13 15:54:50 INFO o.o.b.i.InsteonPLMActiveBinding[:364]- config: more_features -> /etc/openhab/my_own_features.xml
2016-09-13 15:54:50 INFO o.o.b.i.InsteonPLMActiveBinding[:364]- config: more_devices -> /etc/openhab/more_devices.xml
2016-09-13 15:54:50 INFO o.o.b.i.InsteonPLMActiveBinding[:364]- config: service.pid -> org.openhab.insteonplm
2016-09-13 15:54:50 DEBUG o.o.b.i.InsteonPLMActiveBinding[:370]- setting driver listener
2016-09-13 15:54:50 DEBUG o.o.b.i.InsteonPLMActiveBinding[:372]- starting 0 ports
2016-09-13 15:54:50 DEBUG o.o.b.i.internal.driver.Poller[:176]- starting poll thread.
2016-09-13 15:54:50 DEBUG o.o.b.i.internal.driver.Port[:132]- starting port /dev/ttyUSB0
2016-09-13 15:54:51 DEBUG o.o.b.i.i.d.SerialIOStream[:59]- setting port speed to 19200
2016-09-13 15:54:51 INFO o.o.b.i.i.d.SerialIOStream[:66]- successfully opened port /dev/ttyUSB0
2016-09-13 15:54:51 DEBUG o.o.b.i.internal.driver.Port[:239]- starting reader...
2016-09-13 15:54:51 DEBUG o.o.b.i.internal.driver.Port[:373]- starting writer...
2016-09-13 15:54:51 DEBUG o.o.b.i.internal.driver.Port[:382]- writing (0): OUT:Cmd:0x60|
2016-09-13 15:54:51 DEBUG o.o.b.i.i.d.ModemDBBuilder[:50]- querying port for first link record
2016-09-13 15:54:51 DEBUG o.o.b.i.InsteonPLMActiveBinding[:374]- ports started
2016-09-13 15:54:51 DEBUG o.o.b.i.InsteonPLMActiveBinding[:380]- initialization complete, found 1 port!
2016-09-13 15:54:51 DEBUG o.o.b.i.InsteonPLMActiveBinding[:220]- item Input1 binding changed: addr=24.1B.53|prodKey: 00.00.13|feature:Input1
2016-09-13 15:54:51 DEBUG o.o.b.i.internal.driver.Port[:122]- clearing modem db!
2016-09-13 15:54:51 DEBUG o.o.b.i.InsteonPLMActiveBinding[:220]- item indexInput2 binding changed: addr=24.1B.53|prodKey: 00.00.13|feature:indexInput2
2016-09-13 15:54:51 DEBUG o.o.b.i.InsteonPLMActiveBinding[:220]- item indexInput1 binding changed: addr=24.1B.53|prodKey: 00.00.13|feature:indexInput1
2016-09-13 15:54:51 DEBUG o.o.b.i.InsteonPLMActiveBinding[:220]- item Output3 binding changed: addr=24.1B.53|prodKey: 00.00.13|feature:Output3
2016-09-13 15:54:51 DEBUG o.o.b.i.internal.driver.Port[:436]- found modem 1E.7F.62 in device_types: 1E.7F.62|broadcastonoff->GroupBroadcastOnOff(0:1:0)
2016-09-13 15:54:51 DEBUG o.o.b.i.internal.driver.Port[:382]- writing (0): OUT:Cmd:0x69|
2016-09-13 15:54:51 DEBUG o.o.b.i.InsteonPLMActiveBinding[:220]- item Output4 binding changed: addr=24.1B.53|prodKey: 00.00.13|feature:Output4
2016-09-13 15:54:51 DEBUG o.o.b.i.InsteonPLMActiveBinding[:220]- item Output1 binding changed: addr=24.1B.53|prodKey: 00.00.13|feature:Output1
2016-09-13 15:54:51 DEBUG o.o.b.i.InsteonPLMActiveBinding[:220]- item Output2 binding changed: addr=24.1B.53|prodKey: 00.00.13|feature:Output2
2016-09-13 15:54:51 DEBUG o.o.b.i.InsteonPLMActiveBinding[:220]- item Output7 binding changed: addr=24.1B.53|prodKey: 00.00.13|feature:Output7
2016-09-13 15:54:51 DEBUG o.o.b.i.InsteonPLMActiveBinding[:220]- item Input2 binding changed: addr=24.1B.53|prodKey: 00.00.13|feature:Input2
2016-09-13 15:54:51 DEBUG o.o.b.i.InsteonPLMActiveBinding[:220]- item Output8 binding changed: addr=24.1B.53|prodKey: 00.00.13|feature:Output8
2016-09-13 15:54:51 DEBUG o.o.b.i.InsteonPLMActiveBinding[:220]- item Output5 binding changed: addr=24.1B.53|prodKey: 00.00.13|feature:Output5
2016-09-13 15:54:51 DEBUG o.o.b.i.InsteonPLMActiveBinding[:220]- item Output6 binding changed: addr=24.1B.53|prodKey: 00.00.13|feature:Output6
2016-09-13 15:54:51 DEBUG o.o.b.i.InsteonPLMActiveBinding[:581]- got msg: IN:Cmd:0x57|RecordFlags:0xA2|ALLLinkGroup:0x01|LinkAddr:24.1B.53|LinkData1:0x00|LinkData2:0x00|LinkData3:0x00|
2016-09-13 15:54:51 DEBUG o.o.b.i.internal.driver.Port[:382]- writing (0): OUT:Cmd:0x6A|
2016-09-13 15:54:51 DEBUG o.o.b.i.i.d.ModemDBBuilder[:104]- got all link records.
2016-09-13 15:54:51 DEBUG o.o.b.i.i.d.ModemDBBuilder[:130]- MDB ------- start of modem link records ------------------
2016-09-13 15:54:51 DEBUG o.o.b.i.i.d.ModemDBBuilder[:137]- MDB 24.1B.53: RESP group: 01 data1: 00 data2: 00 data3: 00
2016-09-13 15:54:51 DEBUG o.o.b.i.i.d.ModemDBBuilder[:142]- MDB -----
2016-09-13 15:54:51 DEBUG o.o.b.i.i.d.ModemDBBuilder[:142]- MDB -----
2016-09-13 15:54:51 DEBUG o.o.b.i.i.d.ModemDBBuilder[:144]- MDB ---------------- end of modem link records -----------
2016-09-13 15:54:51 INFO o.o.b.i.InsteonPLMActiveBinding[:595]- modem database has 2 entries!
2016-09-13 15:54:51 DEBUG o.o.b.i.InsteonPLMActiveBinding[:600]- modem db entry: 24.1B.53
2016-09-13 15:54:51 DEBUG o.o.b.i.InsteonPLMActiveBinding[:600]- modem db entry: 1E.7F.62
2016-09-13 15:54:51 INFO o.o.b.i.InsteonPLMActiveBinding[:611]- device 24.1B.53 found in the modem database and the modem responds to groups [0x01].
2016-09-13 15:54:51 DEBUG o.o.b.i.internal.driver.Poller[:64]- start polling device 24.1B.53|Input1->Input1(1:0:1)|indexInput2->indexInput2(1:0:1)|indexInput1->indexInput1(1:0:1)|Output3->Output3(1:1:0)|Output4->Output4(1:1:0)|Output1->Output1(1:1:0)|Output2->Output2(1:1:0)|Input2->Input2(1:0:1)|Output7->Output7(1:1:0)|Output8->Output8(1:1:0)|Output5->Output5(1:1:0)|Output6->Output6(1:1:0)
2016-09-13 15:54:51 DEBUG o.o.b.i.i.d.RequestQueueManager[:96]- starting request queue thread
2016-09-13 15:54:51 DEBUG o.o.b.i.i.device.InsteonDevice[:379]- qe taken off direct: Input1(1:0:1) OUT:Cmd:0x62|toAddress:24.1B.53|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0x4C|
2016-09-13 15:54:51 DEBUG o.o.b.i.i.device.InsteonDevice[:399]- next request queue processed in 1498 msec, quiettime = 500
2016-09-13 15:54:51 DEBUG o.o.b.i.internal.driver.Port[:382]- writing (500): OUT:Cmd:0x62|toAddress:24.1B.53|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0x4C|
2016-09-13 15:54:52 DEBUG o.o.b.i.i.device.InsteonDevice[:370]- still waiting for query reply from 24.1B.53 for another 4501 usec
2016-09-13 15:54:54 DEBUG o.o.b.i.i.device.InsteonDevice[:370]- still waiting for query reply from 24.1B.53 for another 2501 usec
2016-09-13 15:54:56 DEBUG o.o.b.i.i.device.InsteonDevice[:370]- still waiting for query reply from 24.1B.53 for another 501 usec
2016-09-13 15:54:58 DEBUG o.o.b.i.i.device.InsteonDevice[:374]- gave up waiting for query reply from device 24.1B.53
2016-09-13 15:54:58 DEBUG o.o.b.i.i.device.InsteonDevice[:379]- qe taken off direct: indexInput2(1:0:1) OUT:Cmd:0x62|toAddress:24.1B.53|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0x4F|
2016-09-13 15:54:58 DEBUG o.o.b.i.i.device.InsteonDevice[:399]- next request queue processed in 500 msec, quiettime = 500
2016-09-13 15:54:58 DEBUG o.o.b.i.internal.driver.Port[:382]- writing (500): OUT:Cmd:0x62|toAddress:24.1B.53|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0x4F|
2016-09-13 15:54:59 DEBUG o.o.b.i.i.device.InsteonDevice[:370]- still waiting for query reply from 24.1B.53 for another 5499 usec
2016-09-13 15:55:01 DEBUG o.o.b.i.i.device.InsteonDevice[:370]- still waiting for query reply from 24.1B.53 for another 3499 usec
2016-09-13 15:55:03 DEBUG o.o.b.i.i.device.InsteonDevice[:370]- still waiting for query reply from 24.1B.53 for another 1499 usec
2016-09-13 15:55:05 DEBUG o.o.b.i.i.device.InsteonDevice[:374]- gave up waiting for query reply from device 24.1B.53
2016-09-13 15:55:05 DEBUG o.o.b.i.i.device.InsteonDevice[:379]- qe taken off direct: indexInput1(1:0:1) OUT:Cmd:0x62|toAddress:24.1B.53|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0x4D|
2016-09-13 15:55:05 DEBUG o.o.b.i.i.device.InsteonDevice[:399]- next request queue processed in 500 msec, quiettime = 500
2016-09-13 15:55:05 DEBUG o.o.b.i.internal.driver.Port[:382]- writing (500): OUT:Cmd:0x62|toAddress:24.1B.53|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0x4D|
2016-09-13 15:55:05 DEBUG o.o.b.i.i.device.InsteonDevice[:370]- still waiting for query reply from 24.1B.53 for another 5500 usec
2016-09-13 15:55:07 DEBUG o.o.b.i.i.device.InsteonDevice[:370]- still waiting for query reply from 24.1B.53 for another 3500 usec
2016-09-13 15:55:09 DEBUG o.o.b.i.i.device.InsteonDevice[:370]- still waiting for query reply from 24.1B.53 for another 1500 usec
2016-09-13 15:55:11 DEBUG o.o.b.i.i.device.InsteonDevice[:374]- gave up waiting for query reply from device 24.1B.53
2016-09-13 15:55:11 DEBUG o.o.b.i.i.device.InsteonDevice[:379]- qe taken off direct: Input2(1:0:1) OUT:Cmd:0x62|toAddress:24.1B.53|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0x4E|
2016-09-13 15:55:11 DEBUG o.o.b.i.i.device.InsteonDevice[:399]- next request queue processed in 500 msec, quiettime = 500
2016-09-13 15:55:11 DEBUG o.o.b.i.internal.driver.Port[:382]- writing (500): OUT:Cmd:0x62|toAddress:24.1B.53|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0x4E|
2016-09-13 15:55:12 DEBUG o.o.b.i.i.d.RequestQueueManager[:132]- device queue for 24.1B.53 is empty!
This was fully working before I installed Insteon terminal so I cannot think of why it has stopped working. Perhaps Java rxtx?
Strange. It’s opening the port alright.If this was a problem with rxtx, it should not be able to open the port. Have you killed all instances of insteon terminal? Would it be difficult to restart openhab?
