Binding addition - 1st look since 2.5

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.

Hi Rich,
I found this code:

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).

1 Like

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?

1 Like

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.

<?xml version="1.0" encoding="utf-8" ?>
    <device productKey="F00:00:FF"
        <model>5010A</model>
        <description>EzRain</description>
        <feature name="lastheardfrom">GenericLastTime</feature>
    </device>
</xml>

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.

Steve

Thanks for the information.

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?

That sounds right. I’ll see if I can fire up the old insteon terminal program and verify.

Ok so this is what I got from the insteon-terminal

>>> ezrain.ping()
sent msg: OUT:Cmd:0x62|toAddress:05.93.D6|messageFlags:0x0F=DIRECT:3:3|command1:0x0F|command2:0x00|
17:48:13: ping got msg: IN:Cmd:0x50|fromAddress:05.93.D6|toAddress:51.67.D2|messageFlags:0x2F=ACK_OF_DIRECT:3:3|command1:0x0F|command2:0x00|
>>> 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 info: IN:Cmd:0x50|fromAddress:05.93.D6|toAddress:04.00.FF|messageFlags:0x81=BROADCAST:1:0|command1:0x01|command2:0xFF|
id dev cat: 04 subcat: 00 firmware: -1 hardware: ff

Does that help?

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.