I recently updgaded my computer and it now comes with OpenHab 4 and java 17. Previously I had OpenHab 2.5 and java 8 or 11. Yes, it’s been a while.
I had extended the original insteon binding with my own for a device called an ezRain, a sprinker. I wrote it in Python although it seems to have a java interface. It’s been so long ago, I don’t remember what I did or how I did it and it looks like everythinhg has changed. So I need some advice on how to go about integrating my ezRain into the insteon binding.
Thanks,
Steve
If it’s 2.5 it’s Java 8. 3 is on Java 11 and 4 is on Java 17.
Anyway, if your solution was originally written in Python, it never was integrated into the binding. There really isn’t a way to have bindings call Python or adding a Java interface.
It’s more likely you have a rule that calls your Python script or you use the exec binding to call your Python script.
If that’s the case, nothing’s really changed. You’d pretty much do it the same way. The syntax will have just changes slightly between OH 2.5 and 3.0.
package org.openhab.binding.insteon.internal.ezrain;
import org.eclipse.smarthome.core.thing.Thing;
import org.openhab.binding.insteon.internal.handler.InsteonDeviceHandler;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class EzrainDeviceHandler extends InsteonDeviceHandler {
private final Logger logger = LoggerFactory.getLogger(EzrainDeviceHandler.class);
public EzrainDeviceHandler(Thing thing) {
super(thing);
logger.debug("In the EzrainDeviceHandler constructor");
}
}
which I guess I wrote but I don’t remember and then two xml files called device_types.xml which defines the features of the EzRain and device_features.xml which specifies the command for those features but I don’t know how it all fits rtogether.
I guess I’ll have to start over but not tonight.
OK, well that code is Java and does look like na add-on. But it’s definitely OH 2.x code (there is no more org.eclipse.smarthome). A lot has changed in the more than seven years since OH 2.0 was released.
I don’t do binding development but I think the docs should get you started with how to set up the build environment and such (that’s changed too).
Thinking back on it, I think I originally wrote it in Python for the insteon terminal software but then when OpenHab went from v1.0 to v2.x, I found I could use configuration files. I’m not sure where that java file fit it.
Reading the insteon documentation now it suggests you can “load your own device_types.xml by referencing it in the network config parameters” but then it doesn’t say where that is. Who is the insteon maintainer? Can they point me in the right direction?
I am the maintainer of the latest beta Insteon binding which introduces an automated device configuration layer. I would be interested in understanding the functionalities you are looking to expose with your ezrain device so I can add support to that addon for this device. Unfortunately the development documentation for that device is not publicly available. Would you be able to share the XML file you are trying to load?
Hi Jeremy, Thanks for getting back to me.
I wrote this file, just to see if I could get the device to come online. The ProductId is what I was using in OpenHab 2.5 but I recently found this document that says the ProductId for the exRain is 0x000001.
The device has 8 valves so I will add <feature name="valve">valveN</valve>
for each valve. I also added these lines to the device_features.xml fiile:
<feature name="Valve0">
<message-dispatcher>DefaultDispatcher</message-dispatcher>
<!-- These deal with responses from the device -->
<!-- <command-handler>PingResponseHandler</command-handler> -->
<message-handler cmd="0x19" valve="0">ValveStatusResponseHandler</message-handler>
<!-- This deals with commands to the device -->
<!-- <command-handler>PingCommand</command-handler> -->
<!-- <command-handler default="true">RequestStatusCommandHandler</command-handler> -->
<command-handler command="OnOffType" valveNum="0">ValveOnOffCommandHandler</command-handler>
<poll-handler>NoPollHandler</poll-handler>
</feature>
I never figured out how to make a general valve type that I could pass the number into so there is one of these for each valve. IIFC the command for ValveOn is 0x40 and ValveOff is 0x041.
That information is already part of the beta addon. It queries a device to get that information and determine its type. However, it currently doesn’t have a supported device type.
The latest binding I maintain is a rewrite of the original one simplifying the device configuration. This is why it doesn’t support loading a custom definition file anymore.
I just realized that the EZRain device is supported by insteon-terminal and you originally wrote the code. I will add the support for that device to the beta addon based on that code.
The ezRain was not the best engineered device, maybe why they stopped making it, and some of the commands don’t work. I think getting the ProductId was one that didn’t work so I would not rely on that mechanism.
In the meantime, is there a way for me to integrate the ezRain into OpenHab 4?
I just went over your old post related to this. That would be an issue for identifying the device. I guess you were never able to get the device to respond to an ID request 0x10 0x00 command?
It does help. The EZRain device can be identified with the devcat and subcat returned in the ID request response. So once I add the support for that device, it will be automatically discovered by the binding.
The status word is decoded as follows:
bits 0-2: the active valve (0-7)
bits 3-4: the active program (0-3)
bit 5: is program sequence running?
bit 6: is V8 configured for pump control
bit 7: a valve is ON.
Based on this UD forum post, my understanding is that only one valve can be on at a time. Turning on a specific valve will turn off the others. When pump control is enabled, valve 8 will turn on but cannot be turned off via the standard command. The other valves control remains the same in that mode while valve 8 staying on.
For example, if pump control is enabled and valve 1 is on, the active valve bits would be 0x00 with the valve on (7) and pump control (6) bits enabled. Likewise, if pump control is disabled and valve 8 is on, the active valve bits would be 0x07 with the valve on bit (7) enabled and the the pump control (6) disabled. When the valve on bit is disabled, the active valve bits wouldn’t matter as it would indicate no valve are on.
Related to the 4 different active programs, do these have specific names or are these customizable? Can these be turned on/off? Your code initializes program on/off command values but these are never used. I assume commands 0x42 <program> and 0x43 <program> should handle this.
Last, you included a way to enable/disable broadcast change message but there is no handling of such message in your code. Would you be able to share how these broadcast messages looks like?
Unfortunately, no workaround with the binding version I am maintaining.
Your understanding of the valves is correct. They are like radio buttons; turning one on turns all the others off but the Off command is needed for the last one.
As far as the programs go, they don’t have names and I was never able to get them to work correctly. Well, I should say that I was never able to determine how they were supposed to work. I had assumed that each program turns valves on and off in some programmed order but I never got it to work as I expected. Within OpenHab it should not matter, I think you can get the same behaviour by making rules.
IIRC, the broadcast message didn’t work either.
Thanks for confirming. So I am almost done with the implementation, I initially thought of using one String channel for the valve showing the current active valve since only one can be on at the time but reverted to using separate Switch channels instead with the last valve show ON if the pump control is enabled. Do you think having one channel would be better?
What do you mean by this statement?
For the program control, I decided to use a Player channel so that a program can be turned on or off via PLAY and PAUSE commands but also support skipping forward or back to the next or previous valve in the program via the NEXT and PREVIOUS commands.
The broadcast message could be a missing link issue preventing your modem from seeing the message. Could you provide a dump of your device database and also a dump of your modem database (only including the links relevant to your sprinkler device)?
I also saw that the device supports timers but I assume you never used these as well. Anyway, it seems to just be configuration management.
Related to the commands response, can you confirm that each commands (0x40 to 0x44) the device receives, it will always respond providing its current status in the cmd2 field with the same format? This is how you implemented in your code and wanted to confirm since it would have adverse consequences with my implementation if it is not the case.
