My initial plan was to keep it fairly simple and emulate what was available in the last HA system I had (Elve). I was just going to expose a method to sync it with the current system time and then let that be triggered from a cron type rule.
Historically, I haven’t needed to sync more than once a day to keep everything in line… But I do seem to lose about 20 seconds a day it seems.
Should we setup another topic for OmniLink Development? I am not sure what is appropriate in this community.
Hi Brian,
I just checked in a change which will set a channel on the omnilink thing with the omnilink system date on startup.
That being said, it doesn’t solve your issue yet.
I think what should be done is add a handleCommand for the systime channel which is now on the omnilink. That would then set the time back on the omnilink. From the rule you would just set the systime item to the current server date, and it should go back to the omnilink. A method would have to be added to the handler to set the date. If you can give me an hour, I might be able to pull that off.
If you would prefer to get in there, that is cool, I could let you take it on too.
Do you remember which method within jomnilink was used to set the date/time over on the omnilink?
If you have the time now, go for it. I wouldn’t be able to tackle it until this weekend.
There is a SetTimeCommand class that implements type Message. Should just need to create the object and pass it to sendAndReceive.
Ok, latest build should have what you need.
The rule should be pretty simple.
rule Foo
when
** cron statement here
then
omnilink_omnilinkBridge_omni_sysdate.postUpdate( new DateTimeType() )
end
Thanks for the quick turnaround!
I am sure I am just missing it somewhere in this thread but where are you putting the latest builds?
Kind of depends how you are installing the binding. I think the easiest way is to enable the IOT marketplace binding, and then getting the latest version of the binding is as easy as uninstalling and re-installing the omnilink binding.
If you are downloading the binding and manually putting it in your addons folder, it can be found here:
https://s3-us-west-2.amazonaws.com/craigham-pub/org.openhab.binding.omnilink-2.1.0-SNAPSHOT.jar
Craig,
I’m hoping that you might pick this up. There is a huge base of installed HAI out there and I’m one that’s had it installed for fifteen years. OPH 1.8 brought my install into the future and I’m hoping for a 2.0 binding to go forward. Running OPH on a Banana Pi and loving it.
Thanks
Oakguy
I am using the addons drop folder right now for the omnilink binding. I switched out mine for yours and everything seems to still work.
However, I do get an error when I try to run that post update:
2017-05-18 22:06:00.051 [ERROR] [ntime.internal.engine.ExecuteRuleJob] - Error during the execution of rule Update Omnilink Time: An error occured during the script execution: The name 'omnilink_omnilinkBridge_omni_sysdate' cannot be resolved to an item or type.
I tried a few other postUpdate and sendCommand methods and didn’t get anywhere.
I will mess around a bit more but do you have any pointers?
It looks like you added the button detection in your the code. Is that working for you in the latest release? I am not seeing anything logged when a button press occurs.
Brian,
How did you resolve the item name (omnilink_omnilinkBridge_omni_sysdate) ? The message indicated an item with that name doesn’t exist.
yes button press detection works for me. Do you have log level set to debug for the binding?
2017-05-19 09:47:33.887 [DEBUG] [nilink.handler.OmnilinkBridgeHandler] - Other event otification, type: 55
2017-05-19 09:47:33.889 [DEBUG] [nilink.handler.OmnilinkBridgeHandler] - First notification: 10
2017-05-19 09:47:33.890 [DEBUG] [nilink.handler.OmnilinkBridgeHandler] - Detect button push: number=2, thing: org.eclipse.smarthome.core.thing.internal.ThingImpl@2ed4b2b0
2017-05-19 09:47:33.892 [DEBUG] [nilink.handler.OmnilinkBridgeHandler] - thing for button press is: omnilink:button:2
2017-05-19 09:47:33.894 [DEBUG] [nding.omnilink.handler.ButtonHandler] - buttonPressed
Not 100% sure what is going on here… From what I can tell openhab is still loading the old binding. I have removed all binding version from all addon folders. Restarted openhab… Yet it keeps starting a binding even with no jars in the addons folder. Its almost acting as if it is cached somewhere…
I am trying to figure out exactly what is going on here. But it sounds like my issues with buttons and the time sync might be a false alarm.
OK… Learning curve for me here. I had to go into karaf and remove the old bundle. Once I did that, I was able to install the new build.
@craigh Is there something I need to do with the 2.0 version of the omnilnk binding to get it to ‘start’? When I swapped out the 1.9 snapshot with the 2.0 version I got nothing in the logs (even with debug mode on). I also had no control of any devices. I did see in the logs that it was registered. This could just be an openhab 2.x vs 1.x thing I am missing…
When I removed the 2.0 binding with karaf and dropped the old 1.9 snapshot in, everything started and I regained control.
Thanks for all your work on this binding.
I would highly recommend you enable the marketplace plugin under the misc tab, and then you can install/uninstall the binding from there. That seems to work pretty well for upgrades.
You’ll just want to make sure you remove the jar from your addons folder.
Thanks. I am on 2.0 release and I think marketplace is only in the 2.1 beta, right?
I am sure I now have it installing correctly… But it just doesn’t do anything when it starts.
Looking at the code it appears for the config ‘host’ changed to ‘ipAddress’. Even if I switch that around, nothing happens when the plugin starts. I would expect it to begin logging (at debug) all the HAI info it finds when it connects.
Here is what I see if I restart the bundle in karaf:
2017-05-20 12:00:49.833 [DEBUG] [ell.impl.action.osgi.CommandExtender] - org.openhab.binding.omnilink (206): Starting destruction process
2017-05-20 12:00:49.833 [DEBUG] [ell.impl.action.osgi.CommandExtender] - org.openhab.binding.omnilink (206): Not an extended bundle or destruction of extension already finished
2017-05-20 12:00:49.833 [DEBUG] [ell.impl.action.osgi.CommandExtender] - org.openhab.binding.omnilink (206): Starting destruction process
2017-05-20 12:00:49.833 [DEBUG] [ell.impl.action.osgi.CommandExtender] - org.openhab.binding.omnilink (206): Not an extended bundle or destruction of extension already finished
2017-05-20 12:00:49.841 [DEBUG] [org.openhab.binding.omnilink ] - ServiceEvent UNREGISTERING - {org.eclipse.smarthome.core.thing.binding.ThingHandlerFactory}={component.name=binding.omnilink, component.id=184, service.id=318, service.bundleid=206, service.scope=bundle} - org.openhab.binding.omnilink
2017-05-20 12:00:49.846 [DEBUG] [org.openhab.binding.omnilink ] - ServiceEvent UNREGISTERING - {org.eclipse.smarthome.config.discovery.DiscoveryService}={component.name=org.eclipse.smarthome.binding.astro.discovery, component.id=185, service.id=319, service.bundleid=206, service.scope=bundle} - org.openhab.binding.omnilink
2017-05-20 12:00:49.854 [DEBUG] [org.openhab.binding.omnilink ] - BundleEvent STOPPING - org.openhab.binding.omnilink
2017-05-20 12:00:49.855 [DEBUG] [ell.impl.action.osgi.CommandExtender] - org.openhab.binding.omnilink (206): Starting destruction process
2017-05-20 12:00:49.855 [DEBUG] [ell.impl.action.osgi.CommandExtender] - org.openhab.binding.omnilink (206): Not an extended bundle or destruction of extension already finished
2017-05-20 12:00:49.855 [DEBUG] [org.openhab.binding.omnilink ] - BundleEvent STOPPED - org.openhab.binding.omnilink
2017-05-20 12:00:49.855 [DEBUG] [org.openhab.binding.omnilink ] - BundleEvent STARTING - org.openhab.binding.omnilink
2017-05-20 12:00:49.860 [DEBUG] [org.openhab.binding.omnilink ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.core.thing.binding.ThingHandlerFactory}={component.name=binding.omnilink, component.id=186, service.id=320, service.bundleid=206, service.scope=bundle} - org.openhab.binding.omnilink
2017-05-20 12:00:49.861 [DEBUG] [org.openhab.binding.omnilink ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.discovery.DiscoveryService}={component.name=org.eclipse.smarthome.binding.astro.discovery, component.id=187, service.id=321, service.bundleid=206, service.scope=bundle} - org.openhab.binding.omnilink
2017-05-20 12:00:49.861 [DEBUG] [mpl.info.InfoBundleTrackerCustomizer] - Ignore incorrect info null provided by bundle org.openhab.binding.omnilink
2017-05-20 12:00:49.861 [DEBUG] [org.openhab.binding.omnilink ] - BundleEvent STARTED - org.openhab.binding.omnilink
@craigh is there anything a user needs to do when the convert from 1.9 binding to the 2.x binding?
I didn’t realize you were on the 1.9 version of the binding until just now.
Yes, configuration for version 2 bindings is different than using the omnilink.cfg file used for 1.x.
There are a couple ways to configure it for 2. I use the paperui to set things up and utilize the discovery. If you log in to the paper ui go to inbox and add omnilink, manual you should see the access point. You can enter your info there. Once you have specified the access point, you can then add devices again and choose omnilink, and then the inbox should populate with all your devices.
Alternatively you can use things and items files to specify all your devices. I haven’t dug into that before, but you should be able to find generic instructions for that in the documentation.
I think based on this, I need to create an things file for omnilink. That is the piece of the puzzle I was missing on the 1.9 to 2.x conversion. It will be a few days before I can do that. Thanks!
@craigh
I finally got some time this afternoon to try and make the switch over. It was a bit tedious, but I did manage to convert over to your version 2.0 driver.
Thanks for all the hard work on this.
I did have a few questions… Two things I am not currently able to make work after switch over are rooms (scenes) and contacts.
I am guessing there is something wrong in my .items file but not sure what to change.
Here is a failing room:
Dimmer Lights_Kitchen_Switch "Kitchen [%d%%]" (Lights_Kitchen) [ "Lighting" ] {channel="omnilink:room:25:status"}
In the sitemap it looks like this:
Selection item=Lights_Kitchen_String label="Scene [MAP(kitchen.map):%s]" icon="kitchen" mappings=['On'=On, 'Off'=Off, "Scene A"=Cook, "Scene B"=Clean, "Scene C"=Eat, "Scene D"=Island]
In the version 1.x of the driver that worked fine. I can’t seem to figure out how to send the on/off and or scene commands to the room binding now?
I am also having trouble with door contacts.
My items files has:
Contact Zones_DeckDoor_Current "Current: [%s]" (Zones_DeckDoor) {channel="omnilink:zone:19:status"}
and my sitemap has:
Text item=Zones_DeckDoor_Current label="Deck Door" icon="frontdoor"
That combo worked fine before. I see no update anymore in the sitemap. Although, I do see the following in the logs:
2017-05-26 17:15:02.160 [DEBUG] [nilink.handler.OmnilinkBridgeHandler] - received status update for zone: 19,status: 1
2017-05-26 17:15:02.161 [DEBUG] [binding.omnilink.handler.ZoneHandler] - handle Zone Status Change to: ON
2017-05-26 17:15:11.450 [DEBUG] [nilink.handler.OmnilinkBridgeHandler] - received status update for zone: 19,status: 0
2017-05-26 17:15:11.450 [DEBUG] [binding.omnilink.handler.ZoneHandler] - handle Zone Status Change to: OFF
Any pointers on the 1.x to 2.x conversion for those items would be appreciated.
Thanks!
@craigh -
Following up on my previous post. Looking at the code I see that zone returns
OnOffType? Should it instead return OpenClosedType?
Edit: When I change the code to use OpenClosedType my zones seem to work correctly. However, I will note that when I restart openhab I don’t see the correct value type (it shows ‘-’) until I open and close a door. Are all the devices being polled on startup?
Edit 2: Updated to OpenClosedType which seems to work. I also had to add the ability to handle refresh in the ZoneHandler. This appears to be working now as it should. @craigh do you want a PR?