NEEO Remote Binding/Transport

Point 2:
there is “nothing” in the file:neeodefinitions.json (2 Bytes) (userdata/neeo/)
i don´t have the file neeodevicedefinitions.json

should i delete neeodefinitions.json and install the binding again?

Thanks for helping!

@Dragonfly
If you would - I just posted a new IO. Give it a try - let’s see if the CPU usage drops (you should be able to leave the IO panel open now) and it should be much quicker on events. Should address your original channel issue as well but that I’m less sure (because I don’t see how that could be happening!).

Note: this version also adds a bunch of stuff from the latest firmware as well - however it’s not real well tested so use at your own risk!

@tmrobert8 continuing on discussion at pull request #2350.

In installed the latest version of the transport. CPU usage is much better now, but I don’t see any things anymore in the connector (No things have been defined). Any idea?

Also, secondary issue with current workaround: after updating the transport, the brain was not discovered anymore. I had to put in the IP of the brain to find it. Switching back to Auto after it connected once allowed it to be discovered again without problem.
The problem could be due to my raspberryPi having multiple interfaces (wired, wireless and vpn virtual interface). I am not using wireless on it, but it connects to an auto-generated IP for that wireless interface. See this log:

2017-11-10 17:11:39.355 [DEBUG] [org.openhab.io.neeo.NeeoService     ] - Brain discovered: NEEO-d487672e at /192.168.0.221 and starting servlet at /neeo/NEEO-d487672e
2017-11-10 17:11:39.393 [WARN ] [g.eclipse.smarthome.core.net.NetUtil] - Invalid address '192.168.0.10/24', will use first interface instead.
2017-11-10 17:11:39.399 [WARN ] [g.eclipse.smarthome.core.net.NetUtil] - Found multiple local interfaces - ignoring 192.168.7.1
2017-11-10 17:11:39.403 [WARN ] [g.eclipse.smarthome.core.net.NetUtil] - Found multiple local interfaces - ignoring 192.168.0.10
2017-11-10 17:11:39.408 [DEBUG] [org.openhab.io.neeo.NeeoService     ] - Started NEEO Listener at /neeo/NEEO-d487672e
2017-11-10 17:11:39.408 [DEBUG] [org.openhab.io.neeo.internal.NeeoApi] - Registering NEEO-d487672e for http://192.168.0.221:3000/v1/api/registerSdkDeviceAdapter using callback http://169.254.89.45:8080/neeo/NEEO-d487672e

Unfortunately, I am not able to use a fixed IP address as the router provided by my cable company does not allow setting fixed IP addresses in the router. And it can obviously not been done on the brain. For now, the workaround of setting it once seems to work though.

neeodefinitions.json is still empty - but was createt new after installing IO.

had to restart OH, because the brain was not online.
after restarting the brain was quickly online, but OH is - 10 min after this - still on 60% cpu and not really online, can´t get commands through it - after uninstalling IO commands where executed and cpu is under 5% again.

openhab.log.xml (203.9 KB)

There was a new FW released from NEEO today - I´ve allready installed this.

EDIT:
After the brains update i had a new IP for the brain, so the binding did not find the brain.
Editing the brain-thing´s IP brought the brian- and room-thing online again, but commands could not be sent. so i deleted both and rediscoverd theme to get it working again.

@Mherwege @Dragonfly
That’s what we get for being on the bleeding edge - there are still some bugs in this version and the things one is one of them. Hopefully I’ll post one soon that is more tested (plus it will include transformations also).

Discovery relies on MDNS implementation in openhab and I know from my own testing is that it is very fragile and will miss notifications alot. Can’t really do a bunch about that.

BTW - multiple interfaces is an issue (I have about 6 of them and I constantly need to set the local ip address [under show more] since openhab always binds on the wrong interface. If the brain is on an wired interface (in addition to a wireless on) - set it’s IP address to lower than a wireless range can get - it will always use that one then

@Mherwege
Just posted a fix for the things one (also includes transformations). Download and try it out.

@Dragonfly
I don’t even know what to do in your case. You’re log is littered with issues (neeo and not neeo based). I think the biggest neeo issue is that it seems you have two versions of the plugin trying to run and probably giving you issues with locks (which is why you get those event more than 5000ms issues).

Here’s what I’d do:

  1. Delete both the binding and IO from the addons and wait a bit for it to uninstall
  2. Shutdown OH
  3. Blow away the cache/tmp directories after making a backup copy of them
  4. Startup OH
  5. Add the IO back (not the binding for now) and see if you still get those “already registered” messages in the log

Ok, here we go again:

I made a fresh installation of OH an added mit Things and Items.
After all is working i only copied the IO to addons.
The brain is shown online at once - i get these errors:

2017-11-12 16:31:03.058 [WARN ] [g.eclipse.smarthome.core.net.NetUtil] - Invalid address '192.168.125.72/24', will use first interface instead.
2017-11-12 16:31:20.243 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.openhab.io.neeo.NeeoService@1e1586a' takes more than 5000ms.
2017-11-12 16:31:20.367 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.openhab.io.neeo.NeeoService@1e1586a' takes more than 5000ms.
2017-11-12 16:31:25.253 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.openhab.io.neeo.NeeoService@1e1586a' takes more than 5000ms.
2017-11-12 16:31:52.524 [INFO ] [work.internal.dhcp.DHCPListenService] - DHCP request for unknown address: 192.168.125.111
2017-11-12 16:32:05.377 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.openhab.io.neeo.NeeoService@1e1586a' takes more than 5000ms.
2017-11-12 16:32:07.801 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.openhab.io.neeo.NeeoService@1e1586a' takes more than 5000ms.
2017-11-12 16:32:10.386 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.openhab.io.neeo.NeeoService@1e1586a' takes more than 5000ms.
2017-11-12 16:32:16.884 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.openhab.io.neeo.NeeoService@1e1586a' takes more than 5000ms.
2017-11-12 16:32:16.889 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.openhab.io.neeo.NeeoService@1e1586a' takes more than 5000ms.
2017-11-12 16:32:30.583 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.openhab.io.neeo.NeeoService@1e1586a' takes more than 5000ms.
2017-11-12 16:32:30.700 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.openhab.io.neeo.NeeoService@1e1586a' takes more than 5000ms.
2017-11-12 16:32:35.592 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.openhab.io.neeo.NeeoService@1e1586a' takes more than 5000ms.
2017-11-12 16:32:42.661 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.openhab.io.neeo.NeeoService@1e1586a' takes more than 5000ms.
2017-11-12 16:32:42.794 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.openhab.io.neeo.NeeoService@1e1586a' takes more than 5000ms.
2017-11-12 16:32:55.867 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.openhab.io.neeo.NeeoService@1e1586a' takes more than 5000ms.
2017-11-12 16:32:56.101 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.openhab.io.neeo.NeeoService@1e1586a' takes more than 5000ms.
2017-11-12 16:33:00.897 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.openhab.io.neeo.NeeoService@1e1586a' takes more than 5000ms.
2017-11-12 16:36:00.095 [INFO ] [ng.homematic.internal.misc.MiscUtils] - Datapoint name '${sysVarAlarmZone1}' contains invalid characters, new Datapoint name '__sysVarAlarmZone1_'
2017-11-12 16:36:00.099 [INFO ] [ng.homematic.internal.misc.MiscUtils] - Datapoint name '${sysVarRainToday}' contains invalid characters, new Datapoint name '__sysVarRainToday_'

192.168.125.111 is the Neeo-Remote

IO is blocking OH again - no commands are executet until i unstall the binding

The 5 second thing has me scratching my head. So what’s happening here is that the transport must listen for any events sent by any binding to determine if that event needs to be forwarded on to the brain (that way as values change in the various bindings - those show up in the brain).

What I’m wondering is if you have a particularly ‘loud’ binding somewhere (that is constantly sending channel updates). That would cause the transport to constantly have to process those events and see if they should be forwarded and maybe the transport can’t process them as fast as the source binding is producing them? Not sure if that’s the case or not - but maybe I can make some changes that would speed up the decision process (of whether to accept the event or not)

Her is my binding list:
binding = homematic,http1,astro,ntp,avmfritz,network,exec,squeezebox,weatherunderground,fritzboxtr0641,systeminfo

homematic is one of the “biggest” - it´s getting states in real-time from about 150 devices.
as i understand you right, i should stop another binding, to find out, if IO is working or not…

ok, i used an old backup…

same bindings installed - only ntp, weatherunderground and systeminfo is active.
working at once.

How do we go on?
In Austria/Germany many users may have HomeMatic installed - is it necessary to find out, if it really is that binding?

Wait until my next update - I’m reworking that part of it to see if I can filter out the events quicker. If that doesn’t work, you’ll probably need to move up to something more powerful that a rasp 3 (I gave up trying to get mine to work in a timely manner - just doesn’t have the horsepower to run alot of stuff).

@Dragonfly
Give the latest a try and let me know…

1 Like

Ok…

No errors, OH not freezing.

cpu load went up from 5 % to 60 %
about 5 minutes later the load was at 35%, things are listed within IO
another 5 minutes later the load is at about 10-15% (Connector and Basic-UI opend).

But… changing from “Brain” to “Things” is triggering a refresh of the Things.
This takes a few minutes - load goes up to 35% at this time.
Maybe it took so long the first time, because I switched between Brain an Things.

That´s really great!
For now i just keep it running… gonna test tomorrow what happens if the Brain looses connection to the network for a longer time and if it reconnects again - if i´m not too excited testing those features :wink:

Is there already a way to configure the Binding with the Smarthome-Designer?

Thank you very much - this is really great!

EDIT:


I have 3 items which are not displayed correctly.
The reload not happend this time when switching to Brain and Things again?!

EDIT2:
Ok, this is just a wordwrap - the Item name is:
Aktor: Büro - Licht/Lüftung/Steckdose/Drucker

@tmrobert8 Thank you for the update.
It looks very good at this point. I can install and run the transport on my raspberryPi and it runs smoothly.
I now hit the next issue. This may be a limitation of NEEO, but still asking. I defined an openHAB light switch in the transport and linked it to a switch on the NEEO. I can switch on and off the light from the NEEO side. However, when I start the recipe with the light on the NEEO, it is always in state off, even when the light is on in openHAB. When I turn the switch on on the NEEO, it keeps the light on. When I then switch the light off on the NEEO, it turns the light off. Changing the switch state in openHAB does not affect the switch position in the NEEO.
So the state of the light is not retrieved from openHAB when starting the recipe to put the switch in the right state.
Any chance to adjust that?

Unplugged the Brain for about an hour.
Brain was shown online after booting the brain.
I was able to edit Things - but the NEEO-App did not find them.
After restarting OH the app is finding Things again.

I can not confirm that the switch is not updating it´s state - sometimes it does but it takes a while.
If you leave the site with the switch and enter it again, it is updating faster…

Is it correct that i can not add a thing to different rooms?
I have a thing with 4 lights switching - 2 in one room, the other 2 in 2 other rooms.
There is also a problem because i can not add a thing to different NEEO-types - i have 4 channels - one turns the WII on, one a Light and so on…

Hope, you understand what i mean - my english isn´t that perfect :frowning:

EDIT:
Unplugged the Brtain again, to test if it possible to execute a Switch, when the Brain is back online - this also does not work - i had to restart OH.

@Dragonfly
Thanks for that picture with the wordwrap. I’ll fix that in the next version. The refresh (of both tabs) only happens when you initially open the panel. From that point on, it will only refresh when you hit the refresh button in the tab header.

The CPU load looks much better now - on a refresh you will get high usage since it has to go through every thing/channel on the system and merge it with what you have defined. There really isn’t much I can do to optimize that one

As for the binding & Smarthome-Designer - I have no idea as I’ve never used that. The only special part of the binding is that the things are dynamically generated on startup - I don’t know how that would affect the designer.

@Mherwege @Dragonfly
Alot of what you said with the switch depends on alot of factors (like did you link the switch up to an power on/off buttons or to the new power state sensor?). Likewise - the brain has been inconsistent on when it asks for the current state of things and I’m still trying to understand why. What I may do is just push the current state of everything whenever we connect to the brain - that way it would be up to date on a connect.

Likewise - multiple interfaces could be a problem still (it is on mine). When we connect to a brain, we need to give it the local IP address for the brain to call back. Unfortunately I get this info from openhab and it seems to choose the wrong interface quite often. So we can send stuff to the brain, but the brain calls back to the wrong ip address. I’m still looking into a solution for that as well (that also prevent the brain from searching for openhab items).

You should be able to add a single thing to multiple rooms (I’ve got my audio system that way). The trick is that you need to, in the NEEO app, search for it twice - first time add it to a room, second time add it to a second room.

@tmrobert8
I linked the switch to a NEEO switc, assuming the switch would update. This is category LIGHT, so all these LIGHTS end up in one recipe per room, one switch per light. When I start the recipe, the state of the switches is all off. Using the switches in NEEO works, and updates my lights. Using the switches in openHAB does work on openHAB side, but does not push the stateupdate to NEEO (it is pushed through everywhere in openHAB).
Should the NEEO ask for a state update? I thought there was a callback function in the SDK. So is it not possible to push the state of the switch on initialization or state update on openHAB side to the NEEO? Will it only work through NEEO polling?
I did configure both the IP of the brain and IP of the openHAB server in the transport. I assume that should resolve the issue of not finding the brain. Before doing that, the brain was discovered, but things configured in the transport were not pushed to NEEO devices. There is a general setting in openHAB (accessible from PaperUI) to set the default subnet of the openHAB server. I saw in the logs when I do not set OH server IP address in the transport it does query that general service. Unfortunately there seems to be a bug in it as it does not see my IP as valid and still defaults to another subnet. There still is a smarthome pull request #4218 open to extend this to IPv6, so I didn’t bother trying to correct it for now. I will come back on it when that gets merged.

Give the latest a try:

  1. Includes detection of brain going offline and restart logic
  2. Includes push of initial state on connect

Note: like the other ones - this isn’t real well tested but should work

EDIT: detection is set on a hard coded 10 second timer right now. Plan to expose that via config later.
EDIT2: and this also includes trying to find the interface the brain is on (based on subnet) - should work in about 99% of the cases where there is multiple interface cards