HAI Omnilink binding not updating outside temp (aux)

Just getting started with openHAB. Very cool stuff !

I have digialdan’s binding working with my Omni IIe but encountered a problem that I haven’t been able to solve: Outdoor temperature won’t update. The correct reading is populated when I start the server but it doesn’t change after that. Tried restarting the browser and updating the items and sitemap file live. The only way I can get this to update is by restarting the openHAB server. Other items like fan status, lights, zones, etc update just fine. It’s only aux that I’m seeing the problem. I stripped the items and site files down to the bare minimum but the problem persists. Here’s my config:

  • Windows 10 64bit
  • Java: java version “1.8.0_91”
  • openHAB: 1.8.3
  • omnilink binding from distributions-1.8.3-addons.zip
  • Omni IIe f/w: 3.5


Group All
Number	Aux_Temp	"Outside Temperature [%d °F]"	(All)	{omnilink="aux_current:15"}


sitemap mysite label="Home" {
	Group item=All

No Rules, Persistence, or Scripts
Here’s a snip from the console in debug mode after startup and after I confirmed on the wall thermostat the outside temp had changed:

08:35:41.832 [DEBUG] [m.r.internal.engine.RuleEngine:77   ] - Started rule engine
08:35:45.433 [DEBUG] [b.o.internal.OmniLinkActivator:34   ] - OmniLink binding has been started.
08:35:45.433 [DEBUG] [i.internal.GenericItemProvider:341  ] - Start processing binding configuration of Item 'Aux_Temp (Type=NumberItem, State=Uninitialized)' with 'OmniLinkGenericBindingProvider' reader.
08:35:45.448 [DEBUG] [OmniLinkGenericBindingProvider:74   ] -  Adding item AUX_CURRENT 15
08:35:45.448 [DEBUG] [o.b.o.internal.OmniLinkBinding:148  ] - all binding changed
08:35:45.464 [DEBUG] [o.b.o.internal.OmniLinkBinding:242  ] - Starting update
08:35:45.464 [DEBUG] [o.b.o.internal.OmniLinkBinding:308  ] - OmniConnectionThread init
08:35:45.464 [DEBUG] [o.b.o.internal.OmniLinkBinding:347  ] - OmniConnectionThread running
08:35:45.464 [DEBUG] [o.b.o.internal.OmniLinkBinding:355  ] - OmniConnectionThread trying to connect
08:35:45.995 [DEBUG] [o.b.o.internal.OmniLinkBinding:360  ] - OmniConnectionThread connected
08:35:46.183 [INFO ] [o.b.o.internal.OmniLinkBinding:398  ] - System: SystemStatus ( timeDateValid = true    year = 16    month = 7    day = 30    dayOfWeek = 6    hour = 8    minute = 31    second = 28    daylightSavings = true    sunriseHour = 5    sunriseMinute = 44    sunsetHour = 20    sunsetMinute = 42    batteryReading = 229    alarms = {}     )
08:35:47.824 [DEBUG] [o.b.o.internal.model.Auxiliary:73   ] - updating item Aux_Temp for type AUX_CURRENT to  57
08:35:47.839 [INFO ] [runtime.busevents             :26   ] - Aux_Temp state updated to 57
08:46:58.778 [DEBUG] [o.b.o.internal.OmniLinkBinding:896  ] - updateDeviceStatus 15 class com.digitaldan.jomnilinkII.MessageTypes.statuses.AuxSensorStatus
08:47:28.837 [DEBUG] [o.b.o.internal.OmniLinkBinding:896  ] - updateDeviceStatus 15 class com.digitaldan.jomnilinkII.MessageTypes.statuses.AuxSensorStatus
08:47:58.794 [DEBUG] [o.b.o.internal.OmniLinkBinding:896  ] - updateDeviceStatus 15 class com.digitaldan.jomnilinkII.MessageTypes.statuses.AuxSensorStatus
08:48:59.700 [DEBUG] [o.b.o.internal.OmniLinkBinding:896  ] - updateDeviceStatus 1 class com.digitaldan.jomnilinkII.MessageTypes.statuses.ExtendedThermostatStatus
08:55:58.664 [DEBUG] [o.b.o.internal.OmniLinkBinding:896  ] - updateDeviceStatus 15 class com.digitaldan.jomnilinkII.MessageTypes.statuses.AuxSensorStatus
08:56:28.625 [DEBUG] [o.b.o.internal.OmniLinkBinding:896  ] - updateDeviceStatus 15 class com.digitaldan.jomnilinkII.MessageTypes.statuses.AuxSensorStatus
08:56:58.712 [DEBUG] [o.b.o.internal.OmniLinkBinding:896  ] - updateDeviceStatus 15 class com.digitaldan.jomnilinkII.MessageTypes.statuses.AuxSensorStatus

This really has me scratching my head since there must be other omnilink binding users with outside temp sensors. I think the is setup in my Omni is correct since Snaplink mobile and the thermostat both display outside temp correctly.
Lastly, I noticed the aux items are not generated when set omnilink:generateItems=true. Looking at the OmnilinkTimesGenerator.java, I don’t see any references to aux. Not a big deal, just thought I should mention it.

Hoping @digitaldan still monitors the forum, even though he doesn’t have an omni anymore :slight_smile:

hmm, I’m not sure why its not updating when other items are. The binding does not poll (except for some audio data), it depends on the omni unit to notify it when a value changes, I had a few temp/humid sensors which worked, so I’m not sure why its not working in your case. As you mentioned I don’t have the hardware and have not touched that code in a very long time.

I have jOmnilinkII Main example running now and can see Aux changing value in RX (0x65 to 0x66 in this case) . Can you think of any reason this won’t propagate up through the openhab binding, or perhaps where I can look?

readBytesEncrypted2: Omni message Length 9
readBytesEncrypted2: Additional bytes to read 0
RX: 0x21 0x09 0x3b 0x08 0x06 0x00 0x0f 0x00 0x65 0x2e 0x00 0xc9 0x06 0x00 0x00 0x00 
readBytesEncrypted2: Data still available after read 0
run: NOTIFICATION: Added message with type 32
readBytesEncrypted2: Bytes available for reading: 0
STATUS_AUX changed
ObjectStatus (  )
readBytesEncrypted2: Omni message Length 9
readBytesEncrypted2: Additional bytes to read 0
RX: 0x21 0x09 0x3b 0x08 0x06 0x00 0x0f 0x00 0x66 0x2e 0x00 0x39 0x06 0x00 0x00 0x00 
readBytesEncrypted2: Data still available after read 0
run: NOTIFICATION: Added message with type 32
readBytesEncrypted2: Bytes available for reading: 0
STATUS_AUX changed
ObjectStatus (  )

adding Steve @swamiller

Ok, Aux is now updating successfully with some changes. Disclaimer: I don’t know Java, Eclipse, Git, or Maven but I managed to follow some good instructions on this site to pull in the source, add some code and and build a jar from the 1.9.0-SNAPSHOT. I simply noticed there wasn’t any code to update status for Aux so I added it by following the format of the code around it. Fortunately, @digitaldan is very consistent with his naming convention. I have no idea if this is right, wrong, or a hack, but it works. It would be awesome if Dan had a look. Here’s what I added to OmniLinkBinding.java:

        * Update a device based on a status message from the system
     * @param status
    protected void updateDeviceStatus(Status status) {

        logger.debug("updateDeviceStatus {} {}", status.getNumber(), status.getClass());

        Integer number = new Integer(status.getNumber());

        if (status instanceof UnitStatus && unitMap.containsKey(number)) {
            Unit unit = unitMap.get(number);
            unit.getProperties().updateUnit((UnitStatus) status);
        } else if (status instanceof ThermostatStatus && thermostatMap.containsKey(number)) {
            logger.debug("Updating thermo " + number);
            Thermostat thermo = thermostatMap.get(number);
            thermo.getProperties().updateThermostat((ThermostatStatus) status);
            // smk start
**        } else if (status instanceof AuxSensorStatus && auxMap.containsKey(number)) {
**            logger.debug("Updating aux " + number);
**            Auxiliary aux = auxMap.get(number);
**            aux.getProperties().updateAuxSensor((AuxSensorStatus) status);
**            updateItemsForDevice(aux);
**            // smk end
        } else if (status instanceof AudioZoneStatus && audioZoneMap.containsKey(number)) {
            logger.debug("Updating audioZone " + number);
            AudioZone az = audioZoneMap.get(number);
            az.getProperties().updateAudioZone((AudioZoneStatus) status);
        } else if (status instanceof AreaStatus && areaMap.containsKey(number)) {
            logger.debug("Updating area " + number);
            Area area = areaMap.get(number);
            area.getProperties().updateArea((AreaStatus) status);
        } else if (status instanceof ZoneStatus && zoneMap.containsKey(number)) {
            logger.debug("Updating zone " + number);
            Zone zone = zoneMap.get(number);
            zone.getProperties().updateZone((ZoneStatus) status);

adding Steve @swamiller

Thanks Sam, I"m in the same boat as you as far as knowing anything about Java but, much like yourself, I’m not beyond hacking together something!

Was there a particular site you used to figure out how to get to the code or did you pull everything you need from the Openhab site?

I used the openhab2 instructions found here http://docs.openhab.org/developers/development/ide.html and then battled the Maven cli (and lost). I eventually used Maven in Eclipse to get the build working.

Thanks Sam! I will take a look a little later today and help you get this into the repo…

@smk take a look at line 908 at https://github.com/digitaldan/openhab/commit/6480d1f9be72838b6a7a7ef5b7d76edc9a32d80a I believe this is what you have done? I have not tried it yet, but I will soon. This commit also catches the common failure case for new users where my crappy item/sitemap generation code craps out and make the binding unusable.

That looks right, Dan. I’ve had this code running for about five days now under Openhab2 without any issues. Once you have the new version in the repo, I’ll pull it down and put some run-time on it. Thanks for taking care of this.

My next endeavor: integrating your Alexa binding!

@digitaldan, let me preface this question with the fact that I can mechanically put most anything together but I am not a programmer in any shape or form…but I can poke around in code and kind of figure out what is going on.

So, with that said, apologize in advance if this is a dumb question.

I am still exploring my options for obtaining current thermostat system status and lock/unlock status from the omnipro. I have a copy of the HAI Omnilink API and I was bouncing the information from that document against your omnilink binding work. Great work, by the way!

The HAI API document shows the heating/cooling values as part of the “Extended Thermostat Status” values, specifically “Data 16” for thermostat 1 and “Data 30” for thermostat 2. Your API also seems to be able to capture the “Access Control Lock Status” (Data 4 for lock 1, Data 9 for lock 2) as well. It looks like the API you built is capable of capturing the data from the board but I’m not sure if it’s retrievable from the OH binding.

Do you know if those messages are currently available to the omnilink binding, and if so how difficult would it be to capture that information?

not dumb questions :wink:

I went back and looked, and yes the library supports this partially, while it can understand the extended message type for therms, the thermo property class does not know how to update its structure from them, so this would need to be done first (I think). The binding is not currently requesting the extended status, it would need to be modified to do so and then understand the extended thermostat bit, the boiler plate code is all there as a template once the library can expose this.

Locks also look to be partially implemented, we know how to read the raw message type but there is no lock property class to do anything with it, this would need to be implemented in the library first, then added to the binding.