So I have written a new method, ValveOnOffCommandHandler() and it seems to build OK. I get lots of warnings and a few errors from other bindings. I have hard coded the valve number for now but I want to test what I have so far. I have added to device_features.xml and device_types.xml.
My biggest hurdle at the moment to how to get the EZRain to link to the hub?
Steve
First, you should probably be able to link the devices simple using the buttons. Have you tried that?
How are you accessing the insteon network: direct PLM, old hub, or hub 2014?
For direct PLM or old hub you can use the HomeLinc software for linking (free download from Insteon, but beware that it’ll wipe your modem link database, so don’t do this if you have a lot of devices already linked w/o using HouseLinc).
If you have the Hub 2014 and the Insteon App supports it, configure it with the App.
I use the Insteon Terminal tool (search for it on github) for linking devices. That’s a very basic tool that my son Dan and I wrote for exactly the purpose of exploring and configuring insteon devices. I vastly prefer it over houselinc, but that’s because I know the code base (and it doesn’t wipe my modem db). That’s what I would use also to figure out how the ezrain device behaves. It’s very quick to code up a command there and to see how the device responds (best to have the equipment right next to you so you can hear the relais click etc).
I couldn’t find detailed developer notes, just bits and pieces here and there. I think the device is category 0x04, and some of the commands are described in this document:
Hi Bernd,
I am using the 2014 insteon hub (2245-222) to access the network.
I only recently noticed the little button on the back on the hub but I can’t get the EZRain to do anything. When I press it’s link button the led does not flash. I thought it was supposed to.
I have installed the insteon-terminal program you recommended but there is no insteon-hub device or EZRain device. I tried added this line to the init.py file.
hub = Modem2413U(“insteon-hub”, “34.27.59”)
and I was able to see some information from the hub.
1
Is there a way to ping all devices on the network with this program?
I’m thinking that my EZRain is broken. The set switch does not seem to do anything so i’d like to see if it is just the switch. It is a few years old.
Thanks,
Steve
Steve,
Can you post the output from hub.getdb() and let me know what the insteon address is of your ez-rain thingy?
On many devices you have to long-press the button for the LED to begin blinking. Make sure to cover all basis before declaring hardware dead. Does it show any sign of life?
BTW, the EZFlora web page says: “This product is not currently compatible with the INSTEON Hub”.
That doesn’t really matter for us, since we are only using the Hub’s PLM modem. Just saying because it probably means you’ll have to resort to low-level means (button pressing) of linking the two devices.
Yes, there is a ping command with which devices can be pinged. Some of them only respond with “ACK” though after they have been linked. Try declaring the EZRain device as an IOLinc device (let’s call it rain for now), it’s similar to that. See what you get back when you do rain.ping(). You should switch on hub.startWatch() so you see all traffic coming to your hub.
Bernd,
hub.getdb()
0000 05.11.99 05.11.99 CTRL 11100010 group: 01 data: 03 00 00
Modem Link DB complete
The address is OC.B1.E1.
That is an old 2413U that I plugged in and linked to make sure I remembered how to do a link.
I tried holding the EZRain set button for 4s, for 10s, for a really long tome, double, and triple taps and the LED never blinks. The LED is on so I guess that counts as a sign of life. I’m wondering if the set button itself is not working.
A long time ago I had written a program for this device and the 2414U from scratch in C but I discovered that the 2414U does not support extended messages which the EZRain uses. I have a document that shows all the EZRain Insteon messages.That says that holding down the link button for 4 seconds is the same as sending a 0x09 command (cmd1). It also says that it reports status as a 0x27 standard broadcast message.
I couldn’t get the IOLinc to work. I checked the py file and it appears to be called IOLinc2450 so I put this in my init.py file but when I start the terminal I get this:
NameError: name ‘IOLinc2450’ is not defined
I grep’d the python directory for devices that have a ping() function and ended up using the thermostat. Then I tried the ping and it got no reply. It’s not looking good.
Steve
Don’t forget the import statement in your init.py:
from iolinc2450 import *
and then something like:
ezrain = IOLinc2450(“ezrain”, “oc.b1.e1”)
then see if you can ping it:
ezrain.ping()
or read its database:
ezrain.getdb()
to see the functions at your disposal, do this:
help(ezrain)
Right now, your modem is just linked as a controller, not a responder to the ezrain. I usually link both ways so the modem picks up any broadcast messages that the device sends out. You may not have to in this case, but you need to find out if your ezrain is linked as a responder to this modem.
Unfortunately, many insteon devices will send a “NACK” unless they are linked to the modem from which they are pinged. Worse, they will not respond to requests for database info (getdb()), unless linked to it.
Also, try to query the id with the ezrain.getId() method. It may just respond to that.
That the set button doesn’t work is a bad sign. That should definitely do something. If you are lucky though you may be able to use ezrain.addResponder(“here your modem insteon address”, 0x01) to link the ezrain without the set button. But that will only work if the ezrain.getdb() gives you any messages back.
Seems like the modem db is perfectly clear, so not much risk fooling around with the modem. May wanna try just linking it again as a controller, i.e. long press the modem set button until it beeps, then long press the ezrain button to see if the modem double beeps and exits link mode.
Let me know how it goes.
OK, adding the import line now allows the IOLinc commands.
ezrain.ping()
sent msg: OUT:Cmd:0x62|toAddress:0C.B1.E1|messageFlags:0x0F=DIRECT:3:3|command1:0x0F|command2:0x01|
MsgHandler got no reply!
ezrain.getId()
sent msg: OUT:Cmd:0x62|toAddress:0C.B1.E1|messageFlags:0x0F=DIRECT:3:3|command1:0x10|command2:0x00|
id got no reply!
ezrain.getdb()
getting db, be patient!
sent db query msg, incoming records: got unexpected msg: IN:Cmd:0x52|rawX10:0xFF|X10Flag:0x80|
got unexpected msg: IN:Cmd:0x52|rawX10:0xFF|X10Flag:0x80|
got unexpected msg: IN:Cmd:0x52|rawX10:0xFF|X10Flag:0x80|
…
did not get full database, giving up!
These X10 messages seems to be sent out all the time and sometimes get taken as a response to a ping ot a getId(). Is it stuck in some X10 mode somehow?
BTW, hub.getId() also returns “id got no reply!”
Steve
Do you even know that it’s the ezrain that is sending the X10 messages? Could be other devices as well.
I’m afraid I’m out of bullets on this one. The device does not respond to anything that usually triggers a response. Has the ezrain ever worked with an Insteon approved solution (houselinc or isy or whatever)?
OK, I decided that it probably was the hardware so I went and bought another ezRain. This is looking a bit more promising. I can now link and ping, and get the daabase. Hwever getId() does not seem to work.
>>> listDevices()
insteon-hub 34.27.59
sprinkler 05.93.D6
>>> hub.getdb()
0000 05.11.99 05.11.99 CTRL 11100010 group: 01 data: 03 00 00
0000 sprinkler 05.93.D6 RESP 10100010 group: 01 data: 00 00 00
0000 sprinkler 05.93.D6 CTRL 11100010 group: 01 data: 03 00 09
Modem Link DB complete
>>> ezrain.ping()
sent msg: OUT:Cmd:0x62|toAddress:05.93.D6|messageFlags:0x0F=DIRECT:3:3|command1:0x0F|command2:0x01|
ping got msg: IN:Cmd:0x50|fromAddress:05.93.D6|toAddress:34.27.59|messageFlags:0x2F=ACK_OF_DIRECT:3:3|command1:0x0F|command2:0x01|
>>> ezrain.getId()
sent msg: OUT:Cmd:0x62|toAddress:05.93.D6|messageFlags:0x0F=DIRECT:3:3|command1:0x10|command2:0x00|
id got ack!
id got no reply!
The getId() sends out a standard direct message with cmd1=0x10. According to the docs I have exRain should first send an Ack which it appears to do and then send a “Set Button Pressed” broadcast message which appears to be missing.
I’d like to see what other commands I can get to work in your terminal program. If I copy the iolinc2450.py file, rename it to ezrain.py and add an import line to the init.py file, what else do I need to get it to compile?
Thanks,
Steve
Good, that’s progress!
As far as compiling insteon terminal: an import statement in your init.py for the new class, that should be all.
Bernd,
I had turned the intseon-terminal logging level up to TRACE and I’m seeing that I get a response of “Got no reply” before the outgoing message is even sent.
Where is that timeout set?
Steve
I have no idea, I’d have to look in the code, but I doubt the timeout is too short.
What command are you sending? Does anything else work?
So I wrote a setValveOn(int) method. Here is the output from insteon-terminal
Insteon Terminal
Connecting
Connected
Terminal ready!
>>> >>> setLogLevel(“TRACE”)
>>> ezrain.setValveOn(1)
sent msg: OUT:Cmd:0x62|toAddress:05.93.D6|messageFlags:0x0F=DIRECT:3:3|command1:0x40|command2:0x01|
DumpDataMsgHandler got no reply!
but in the terminal window I get:
$ ./insteon-terminal
14:37:44.122 [Thread-3] DEBUG us.pfrommer.insteon.msg.IOPort - Msg written: OUT:Cmd:0x62|toAddress:05.93.D6|messageFlags:0x0F=DIRECT:3:3|command1:0x40|command2:0x01|
14:37:56.727 [Thread-2] TRACE us.pfrommer.insteon.msg.MsgReader - read buffer: len 20 data: 02620593D60F40010602500593D63427592F4001
14:37:56.728 [Thread-2] TRACE us.pfrommer.insteon.msg.MsgReader - processing data: len 20 data: 02620593D60F40010602500593D63427592F4001
14:37:56.729 [Thread-2] TRACE us.pfrommer.insteon.msg.MsgReader - header length expected: 6 extended: false
14:37:56.729 [Thread-2] TRACE us.pfrommer.insteon.msg.MsgReader - msgLen expected: 9
14:37:56.730 [Thread-2] TRACE us.pfrommer.insteon.msg.MsgReader - keeping buffer len 11 data: 02500593D63427592F4001
14:37:56.731 [Thread-2] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x62|toAddress:05.93.D6|messageFlags:0x0F=DIRECT:3:3|command1:0x40|command2:0x01|ACK/NACK:0x06|
14:37:56.732 [Thread-2] TRACE us.pfrommer.insteon.msg.MsgReader - processing data: len 11 data: 02500593D63427592F4001
14:37:56.732 [Thread-2] TRACE us.pfrommer.insteon.msg.MsgReader - header length expected: 9 extended: false
14:37:56.732 [Thread-2] TRACE us.pfrommer.insteon.msg.MsgReader - msgLen expected: 11
14:37:56.733 [Thread-2] TRACE us.pfrommer.insteon.msg.MsgReader - keeping buffer len 0 data:
14:37:56.733 [Thread-2] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x50|fromAddress:05.93.D6|toAddress:34.27.59|messageFlags:0x2F=ACK_OF_DIRECT:3:3|command1:0x40|command2:0x01|
14:37:56.734 [Thread-2] TRACE us.pfrommer.insteon.msg.MsgReader - processing data: len 0 data:
14:37:56.734 [Thread-2] TRACE us.pfrommer.insteon.msg.MsgReader - msgLen expected: -1
14:37:56.734 [Thread-2] TRACE us.pfrommer.insteon.msg.MsgReader - keeping buffer len 0 data:
so I think eveything is working as expected but its taking too long.
I had a quick look around in the code for a timeout
$ grep -R -i timeout *
Binary file bin/us/pfrommer/insteon/msg/serial/SerialIOStream.class matches
Binary file bin/us/pfrommer/insteon/msg/hub/LegacyHubStream.class matches
Binary file bin/us/pfrommer/insteon/msg/hub/LegacyHubStream$NonBlockingStream.class matches
Binary file lib/hub/httpclient-4.3.6.jar matches
Binary file lib/hub/httpclient-cache-4.3.6.jar matches
Binary file lib/jython-standalone-2.7-b1.jar matches
python/querier.py: def waitForReply(self, timeout):
python/querier.py: self.condition.wait(timeout)
Binary file python/querier$py.class matches
src/us/pfrommer/insteon/msg/serial/SerialIOStream.java: //Do receive timeout so we can check if the reader has to stop
src/us/pfrommer/insteon/msg/serial/SerialIOStream.java: m_port.enableReceiveTimeout(1000);
src/us/pfrommer/insteon/msg/hub/LegacyHubStream.java:import java.net.SocketTimeoutException;
src/us/pfrommer/insteon/msg/hub/LegacyHubStream.java: m_socket.setSoTimeout(1000);
src/us/pfrommer/insteon/msg/hub/LegacyHubStream.java: } catch (SocketTimeoutException e) {
src/us/pfrommer/insteon/msg/hub/LegacyHubStream.java: } catch (SocketTimeoutException e) {
but I couldn’t see where waitForReply is called from.
Steve
The timeout is in the Querier class:
def sendMsg(self, msg):
self.started()
iofun.addListener(self)
if self.timer:
self.timer.cancel()
self.timer = Timer(5.0, self.giveUp)
self.timer.start()
iofun.writeMsg(msg)
out("sent msg: " + msg.toString())
# out("started timer!")
Where it starts the timer. I doubt the problem with a timeout since the reply message comes almost instantly (and looks like it’s actually working, do you hear the relay click?). It’s the message handler that you are setting (in this case the DumpDataMsgHandler) that probably is just dropping the reply message without taking any action. I don’t understand why you took the DumpDataMsgHandler (which is from the thermostat) rather than the DefaultMsgHandler in the IOLinc2450. But even the DumpDataMsgHandler should print out something when data comes unless you removed the print statements.
I suggest you fork a repository on github and push your changes to that repository so I have a snapshot of what your code actually looks like.
Also, you don’t need to do trace logging. It’s enough to do modem.startWatch() and you’ll see all incoming messages printed.
There is something weird going on with the timing of messages. I’m using the setLogLevel() because it shows the time that messages get sent whereas hub.startWatch() does not. I added time info to the messages that get printed in insteon-terminal and this is what I get:
$ ./insteon-terminal
13:47:32.236 [Thread-3] DEBUG us.pfrommer.insteon.msg.IOPort - Msg written: OUT:Cmd:0x62|toAddress:05.93.D6|messageFlags:0x0F=DIRECT:3:3|command1:0x44|command2:0x02|
13:47:50.024 [Thread-2] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x62|toAddress:05.93.D6|messageFlags:0x0F=DIRECT:3:3|command1:0x44|command2:0x02|ACK/NACK:0x06|
13:47:50.026 [Thread-2] DEBUG us.pfrommer.insteon.msg.IOPort - Msg received: IN:Cmd:0x50|fromAddress:05.93.D6|toAddress:34.27.59|messageFlags:0x2F=ACK_OF_DIRECT:3:3|command1:0x44|command2:0x00|
and the command that produced that output were:
Insteon Terminal
Connecting
Connected
Terminal ready!
>>> setLogLevel("DEBUG")
>>> hub.startWatch()
>>> ezrain.getValveStatus()
13:46:56: sent msg: OUT:Cmd:0x62|toAddress:05.93.D6|messageFlags:0x0F=DIRECT:3:3|command1:0x44|command2:0x02|
started timer of 40.000000s!
13:47:36: ezRainStatusMsgHandler got no reply!
modem got msg: IN:Cmd:0x50|fromAddress:05.93.D6|toAddress:34.27.59|messageFlags:0x2F=ACK_OF_DIRECT:3:3|command1:0x44|command2:0x00|
so you can see that the getValveStatus() message was entered in insteon-terminal at 13:46:56 but the log message did not show in msg.IOPort up until 13:47:32.236 ie 36s later! There is also a long delay on the incomong side. IOPort received the messages at 13:47:50 but they were no seen by ezRainStatusMsgHandler (something I wrote to print out the returned status) until after the timeout expired.
I will look into getting a github account.
I am making some progress now.
Thanks,
Steve
Hi Bernd,
I have created a git account, forked your repo and pushed my changes to my repo. There is one new file called python/ezrain.py. Hopefully you can see it.
I discovered that the timing issues I was having have something to do with the hub.startWatch() method. After I issue that command, I can no longer reset the terminal. It just hangs.
Most of my standard length commands seem to work but I cannot get any extended commands or responses. I have tried sending extended commands where standard length is indicated and I get back an ACK but no data. BTW the 14th data word always seems to contain junk.
Feel free to alter my code, I’m not a python or java guy, and make any suggestions.
Thanks,
Steve
Steve,
Where is your repo on github, can you provide a link?
Yes, it’s possible that the startWatch() does bad things to the hub thread. I usually run on a PLM and it generally works there, although I also have cases where reset no longer works. It has do do with a thread not being released but I have not tracked down all cases.
Bernd
Ok. Looks good already, please submit a pull request and @dan_pfrommer will merge it.