NEEO Remote Binding/Transport

@tmrobert8
The light switches are defined in OH and exposed to the NEEO brain through the transport.

Here is the log for trying to add a new device. I did remove most of the response of the query as it was over the 32000 character limit on this forum. Could that be an issue? I switched off the firewall. It does not make a difference. I query on ‘Openhab’:

2018-01-25 15:32:13.071 [DEBUG] [ternal.servletservices.SearchService] - Search 'Openha', response: [{"item":{"apiversion":"1.0","adapterName":"nikohomecontrol:onOff:440e003a24e6:7","type":"LIGHT","manufacturer":"openHAB","name":"Inkom","tokens":"","setup":{},"deviceCapabilities":[],"device":{"name":"Inkom","tokens":[]},"capabilities":[{"name":"Licht_Inkom","label":"Inkom","type":"switch","path":"%2Fdevice%2Fnikohomecontrol%3AonOff%3A440e003a24e6%3A7%2FLicht_Inkom%2F1%2Fswitch%2Factor","sensor":"Licht_Inkom"},{"name":"Licht_Inkom","label":"Inkom","type":"sensor","path":"%2Fdevice%2Fnikohomecontrol%3AonOff%3A440e003a24e6%3A7%2FLicht_Inkom%2F1%2Fswitch%2Fsensor","sensor":{"type":"binary"}}],"id":0},"score":2,"maxScore":-1},{"item":{"apiversion":"1.0","adapterName":"nikohomecontrol:onOff:440e003a24e6:6","type":"LIGHT","manufacturer":"openHAB","name":"Trap","tokens":"","setup":{},"deviceCapabilities":[],"device":{"name":"Trap","tokens":[]},"capabilities":[{"name":"Licht_Trap","label":"Trap","type":"switch","path":"%2Fdevice%2Fnikohomecontrol%3AonOff%3A440e003a24e6%3A6%2FLicht_Trap%2F1%2Fswitch%2Factor","sensor":"Licht_Trap"},{"name":"Licht_Trap","label":"Trap","type":"sensor","path":"%2Fdevice%2Fnikohomecontrol%3AonOff%3A440e003a24e6%3A6%2FLicht_Trap%2F1%2Fswitch%2Fsensor","sensor":{"type":"binary"}}],"id":1},"score":2,"maxScore":-1}, ... ,{"item":{"apiversion":"1.0","adapterName":"neeo:device-6360880053269561344:d487672e:room:device","type":"LIGHT","manufacturer":"Wenzhou TKB Control System","name":"Boilerpomp (NEEO d487672e)","tokens":"","setup":{},"deviceCapabilities":[],"device":{"name":"Boilerpomp (NEEO d487672e)","tokens":[]},"capabilities":[{"name":"Boilerpomp Aan","label":"Boilerpomp Aan","type":"button","path":"%2Fdevice%2Fneeo%3Adevice-6360880053269561344%3Ad487672e%3Aroom%3Adevice%2FBoilerpompNEEOD487672e_Macros_TurnOn%2F1%2Fbutton%2Fon"},{"name":"Boilerpomp Uit","label":"Boilerpomp Uit","type":"button","path":"%2Fdevice%2Fneeo%3Adevice-6360880053269561344%3Ad487672e%3Aroom%3Adevice%2FBoilerpompNEEOD487672e_Macros_TurnOff%2F1%2Fbutton%2Fon"}],"id":51},"score":2,"maxScore":-1}]

@tmrobert8
And here is the log for switching the light from the NEEO app. I don’t see the transport picking up the event. Both binding and transport are in debug mode.

2018-01-25 15:43:17.716 [DEBUG] [eo.handler.NeeoForwardActionsServlet] - handleForwardActions {"action":"Licht_Nachthal","device":"Nachthal","room":"Boven","actionparameter":true}

==> /var/log/openhab2/events.log <==

2018-01-25 15:43:17.724 [vent.ChannelTriggeredEvent] - neeo:brain:d487672e:forwardActions triggered {"action":"Licht_Nachthal","device":"Nachthal","room":"Boven","actionparameter":true}

==> /var/log/openhab2/openhab.log <==

2018-01-25 15:43:17.744 [INFO ] [.eclipse.smarthome.model.script.neeo] - action received: {"action":"Licht_Nachthal","device":"Nachthal","room":"Boven","actionparameter":true}

2018-01-25 15:43:17.749 [DEBUG] [inding.neeo.handler.NeeoBrainHandler] - Checking connectivity to 192.168.0.107:3000 - successful

2018-01-25 15:43:20.781 [DEBUG] [eo.handler.NeeoForwardActionsServlet] - handleForwardActions {"action":"Licht_Nachthal","device":"Nachthal","room":"Boven","actionparameter":false}

==> /var/log/openhab2/events.log <==

2018-01-25 15:43:20.790 [vent.ChannelTriggeredEvent] - neeo:brain:d487672e:forwardActions triggered {"action":"Licht_Nachthal","device":"Nachthal","room":"Boven","actionparameter":false}

==> /var/log/openhab2/openhab.log <==

2018-01-25 15:43:20.793 [INFO ] [.eclipse.smarthome.model.script.neeo] - action received: {"action":"Licht_Nachthal","device":"Nachthal","room":"Boven","actionparameter":false}

2018-01-25 15:43:23.113 [DEBUG] [org.openhab.io.neeo.internal.NeeoApi] - Checking connectivity to 192.168.0.107:3000 - successful

@tmrobert8
Progress! I was able to make discovery work again! I had all things exposed to NEEO. That indeed seems to be too much to handle. When I switched off the ‘Expose All’ and ‘Expose NEEO Binding’ parameters and removed the NEEO type from most of the things in the transport, I could add things to the NEEO again.
The things I added then did work correctly. All the old things that were still there did not. So somewhere the link must have been lost in all the fiddling I have done. I will re-add them all to the brain. I expect it will work again then.
One more thing: The Weather Underground binding has image channels. I noticed you can now show images from URL’s. Any chance you can show the images from an image channel? That might allow me to show the weather on the remote :smile:

Interesting - there must be some limit in the brain for what it will take and process - you must have gone beyond that limit and it probably rejected your whole response (probably because it was malformed then).

I think I know why the old things don’t work. When the transport start up, it registers itself as an SDK with the brain. Part of the registration includes an ID of the SDK. In one of the versions, I changed that ID (I had a static string and I changed it to be the UUID of the openhab instance ). I needed to make that change because if you had two openHAB instances running - they needed unique IDs to function correctly. I didn’t think that would matter (since the brain would still use the same callback) - but maybe it did.

I’ve asked the question to NEEO about the limit - I’ll let you know when I hear back. I may make a change to the transport to limit the result to the top ?12? (or probably make it configurable with 12 as the default) best matches to prevent this from occurring in the future.

As for the Weather Underground binding - unfortunately the brain ONLY takes URLs - not direct images. However (and I’m talking off the top of my head because I’m not sure if this is possible) - you might be able to:

  1. Create a virtual item as a string type
  2. Create a rule that is triggered on startup or when the weather icon item changes and sets that virtual item string to the REST API URL for the icon item
  3. Create a virtual device in the transport containing the virtual item and add it to NEEO

That way the virtual item contains the rest url and can be added to NEEO as an image. NEEO would then call that URL to retrieve the image.

Since NEEO only calls the url if the url changes (and the rest url wouldn’t change) - the rule would have to have a counter to append to the call to make it different each time it changes. Something like “https://192.168.1.x:8080/rest/api/item/iconitemname&id=1” then the next change would be “https://192.168.1.x:8080/rest/api/item/iconitemname&id=2”. I’m pretty sure the rest api ignores query strings - so that should work.

EDIT
In fact - wouldn’t even need a counter - you could use the current time. All NEEO cares about is if the URL changes (doesn’t care about the content of the change) and openHAB ignores the query string - so you could put anything in the querystring as long as it’s different from the last querystring

FYI - just uploaded a new transport version that supports a ‘searchLimit’ configuration parameter (defaults to 12 - which is the maximum the brain will show). This will limit the search to the top X devices sorted by the score of the match.

This will get around @Mherwege issue of returning too many items

FYI - since the old PR was getting unicorns in many browsers, we closed that PR and opened a new one - here is the link to the latest

@tmrobert8 Thank you for the suggestions to get images displayed.
Unfortunately, that did not work. openHAB does not accept the extra query string. On top of that, the images from the Weather Underground binding , served by the openHAB REST api, were GIFs. And it looks like NEEO only supports JPG and PNG.
I worked around it with a set of icons in PNG format stored in the conf/html folder and passing these URLs. I now have weather icons showing on the NEEO.
I made all weather items text visible as shortcuts in a recipe on the NEEO. I typically show condition, min/max temp, rain quantity and rain probability. Showing all of these as separate labels fills the NEEO screen. Also wrapping cannot be controlled. I tried to work around it by concatenating everything in one string, with linefeeds (\n) in the string. But NEEO eats the linefeeds, so everything is still concatenated. Another ‘feature’ of the NEEO UI code that could benefit from some improvement.

Everything on the remote is HTML - so you could try "<BR/>" instead of “/n”. I doubt that would work because they should be encoding the lines - so it should display "<BR/>" rather than give you a break. However, if it does do a break - that opens things up to all sorts of hacking possibilities :wink:

@tmrobert8

<BR/> does indeed not give a break, but is shown as is.
A few more little ‘features’:

  • icons with transparent background show background as black on the remote, but fine on the app.
  • °C is shown fine on the app, but as ‘degC’ on the remote. Trying to replace it by \&deg; does not work.

It would indeed be very nice to have a full HTML object to put on the screen, rather than just a text label.

The APP/EUI is straight up angularjs being shown by your browser (or the app browser) - so all your html goodies will work fine with it. However, the remote/TR2 uses some type of custom interpreter that converts their XML format (which is sent between the brain and the remote) to HTML that is then shown in remote’s browser. That interpretter probably encodes all text before sending to the browser (would be my guess) - so you lose the ability to inject raw HTML.

BTW - browse http://brainip:3000/projects/home/tr2/gui_xml if you want to see their XML setup on your remote.

New version of the transport was posted. Changes:

  1. Added an icon to the brains page that will bring up the EUI for the brain
  2. Added an icon to the brains page to display the log file from the brain

Both are minor changes. Please note this also includes changes from the review which shouldn’t really be visible

So last post here was 26 days ago.
I just found the thread and being fresh to OpenHab, I downloaded the jar’s and dropped them into the addons folder of openhab.
I now have a Neeo binding under bindings, and a Neeo Transport under Services, I also can access the Neeo transporte ui of openhab. However it does not detect the Neeo, I tried to add it manually in the Neeo transport OpenHab ui, and after a long time it showed up, but is showing offline.
I tried accessing the 3000 and the 3200 port, and it is responding.
But I’m starting to think that maybe this plugin stopped working with the recent firmware update of Neeo?

@Eldaria

The binding/transport works just fine with the latest firmware. Usually when stuff like this happens - it’s due to firewall issues - you may want to try (temporarily) turning off any firewalls and add the device (just the IP address in case you added the port to it). If that doesn’t work, some more information would be needed (what is it running on [win, linux, nas, etc], did you try to access it from the same machine as openhab, did the binding connect, etc).

Thanks,
Tim

Odd, I just logged in and now it is showing as OK, and I did not do anything with firewalls. Well happy days, now I can try it out. Thanks a lot for the effort!

@tmrobert8 Tim, I noticed the following in my log when starting a recipe from NEEO. It does not seem to do much harm, but the null should probably not be there.

2018-03-06 09:42:49.574 [vent.ChannelTriggeredEvent] - neeo:brain:d487672e:forwardActions triggered {"action":"launch","recipe":"Boilerpomp"}

==> /var/log/openhab2/openhab.log <==

2018-03-06 09:42:49.567 [WARN ] [eclipse.jetty.servlet.ServletHandler] - /neeo/binding/d487672e/forwardactions

java.lang.NullPointerException: null

	at org.openhab.binding.neeo.internal.NeeoRoomProtocol.processAction(NeeoRoomProtocol.java:115) [253:org.openhab.binding.neeo:2.3.0.201801250225]

	at org.openhab.binding.neeo.handler.NeeoRoomHandler.processAction(NeeoRoomHandler.java:291) [253:org.openhab.binding.neeo:2.3.0.201801250225]

	at org.openhab.binding.neeo.handler.NeeoBrainHandler$1.post(NeeoBrainHandler.java:185) [253:org.openhab.binding.neeo:2.3.0.201801250225]

	at org.openhab.binding.neeo.handler.NeeoForwardActionsServlet.doPost(NeeoForwardActionsServlet.java:82) [253:org.openhab.binding.neeo:2.3.0.201801250225]

	at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [31:javax.servlet-api:3.1.0]

	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [31:javax.servlet-api:3.1.0]

	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:848) [88:org.eclipse.jetty.servlet:9.3.22.v20171030]

	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:584) [88:org.eclipse.jetty.servlet:9.3.22.v20171030]

	at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71) [191:org.ops4j.pax.web.pax-web-jetty:6.0.7]

	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) [87:org.eclipse.jetty.server:9.3.22.v20171030]

	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) [85:org.eclipse.jetty.security:9.3.22.v20171030]

	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226) [87:org.eclipse.jetty.server:9.3.22.v20171030]

	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180) [87:org.eclipse.jetty.server:9.3.22.v20171030]

	at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:284) [191:org.ops4j.pax.web.pax-web-jetty:6.0.7]

	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512) [88:org.eclipse.jetty.servlet:9.3.22.v20171030]

	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) [87:org.eclipse.jetty.server:9.3.22.v20171030]

	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112) [87:org.eclipse.jetty.server:9.3.22.v20171030]

	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) [87:org.eclipse.jetty.server:9.3.22.v20171030]

	at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80) [191:org.ops4j.pax.web.pax-web-jetty:6.0.7]

	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) [87:org.eclipse.jetty.server:9.3.22.v20171030]

	at org.eclipse.jetty.server.Server.handle(Server.java:534) [87:org.eclipse.jetty.server:9.3.22.v20171030]

	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:333) [87:org.eclipse.jetty.server:9.3.22.v20171030]

	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251) [87:org.eclipse.jetty.server:9.3.22.v20171030]

	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283) [79:org.eclipse.jetty.io:9.3.22.v20171030]

	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108) [79:org.eclipse.jetty.io:9.3.22.v20171030]

	at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) [79:org.eclipse.jetty.io:9.3.22.v20171030]

	at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303) [90:org.eclipse.jetty.util:9.3.22.v20171030]

	at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148) [90:org.eclipse.jetty.util:9.3.22.v20171030]

	at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136) [90:org.eclipse.jetty.util:9.3.22.v20171030]

	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671) [90:org.eclipse.jetty.util:9.3.22.v20171030]

	at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589) [90:org.eclipse.jetty.util:9.3.22.v20171030]

	at java.lang.Thread.run(Thread.java:748) [?:?]

@Mherwege
Thanks - I’m pretty sure this is fixed in the latest code (atleast when I look at the source code - it appears to be fixed)

@tmrobert8 - got a lot of these errors:

2018-03-12 12:37:29.152 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception
javax.ws.rs.ProcessingException: URI is not absolute
	at org.glassfish.jersey.client.ClientRuntime.invoke(ClientRuntime.java:264) ~[?:?]
	at org.glassfish.jersey.client.JerseyInvocation$1.call(JerseyInvocation.java:684) ~[?:?]
	at org.glassfish.jersey.client.JerseyInvocation$1.call(JerseyInvocation.java:681) ~[?:?]
	at org.glassfish.jersey.internal.Errors.process(Errors.java:315) ~[?:?]
	at org.glassfish.jersey.internal.Errors.process(Errors.java:297) ~[?:?]
	at org.glassfish.jersey.internal.Errors.process(Errors.java:228) ~[?:?]
	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:444) ~[?:?]
	at org.glassfish.jersey.client.JerseyInvocation.invoke(JerseyInvocation.java:681) ~[?:?]
	at org.glassfish.jersey.client.JerseyInvocation$Builder.method(JerseyInvocation.java:437) ~[?:?]
	at org.glassfish.jersey.client.JerseyInvocation$Builder.post(JerseyInvocation.java:343) ~[?:?]
	at org.openhab.binding.neeo.internal.net.HttpRequest.sendPostJsonCommand(HttpRequest.java:88) ~[17:org.openhab.binding.neeo:2.3.0.201801250225]
	at org.openhab.binding.neeo.handler.NeeoForwardActionsServlet.lambda$0(NeeoForwardActionsServlet.java:88) ~[17:org.openhab.binding.neeo:2.3.0.201801250225]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
	at java.lang.Thread.run(Thread.java:748) [?:?]
Caused by: java.lang.IllegalArgumentException: URI is not absolute
	at java.net.URI.toURL(URI.java:1088) ~[?:?]
	at org.glassfish.jersey.client.internal.HttpUrlConnector._apply(HttpUrlConnector.java:340) ~[?:?]
	at org.glassfish.jersey.client.internal.HttpUrlConnector.apply(HttpUrlConnector.java:285) ~[?:?]
	at org.glassfish.jersey.client.ClientRuntime.invoke(ClientRuntime.java:255) ~[?:?]
	... 18 more

Did you setup a forwarding URL in the configuration for the binding? If so, what was it?

I made an update to the latest Snapshot - everything in userdata was deleted.
Most stuff is configured in files - so i just addet all Items again.

I did not enter a URL anywhere - i even did not find where to enter the forwarding URL in the configuration for the binding - there is nothing to configure?!