I’m using the apt oackaged OpenHab on Raspbian (having lost my previous install to a corrupt sd card) and can,t seem to get any “item” to show its value in a text field in the web ui or iOs App.
I’ve reset .rules, .items, .sitemap to the latest demo package - so nothing is custom in my files yet when viewed in the web ui temperature fields, even DateTime simply display as:
Outside Temperature. -C``
Date. -,-.-.-
These items, despite being per default config never seem to have any values. At least none that are visible in the UI.
side note:
Prior to resetting everything to the demo config - I had experimented witht he DSCalarmBinding. Same problem. No values in Ui but in events.log I can see entries indicating zome status changing. E g.
ZONE_5_GENERALSTATUS is set to CLOSED
....
I’m sure I’m missing something obvious but any bump in the right direction woukd be very appreciated.
I’m having this problem with both Openhab 1.8 (1/14 build) and Openhab 2 (build #106 from 2016.01.27).
Sorry I can’t help but I hear misery loves company.
As an experiment, I stripped the .items file down to only one item… a DateTime item usimg the NTPbinding as per the demo configuration.
I then added a simple 1 minute cron based rule to log its value. This line:
logInfo("Values", "Current Date is" + Date)
Will output the following to openhab.log:
Current Date is {Type: DateTime, State: Uninitialized}
I’m pretty sure in my previous openhab config I didn’t have any issues with simply declaring an item so not sure if I have to change persistence or startup rules to initialize them allow OH to store and use items.
Any suggestions welcomed.
PS. OpenHab v 1.8.0, Java: Oracle 1.7.4. Both installed via apt.
I restarted installing from scratch and ran OH2 with no configuration and it built the demo config automatically and gave me demo values.
That indicated to me that I could (at least now) get values.
I then added my stuff and found that my ecobee binding wasn’t working because I had to re-authenticate and get a new key from ecobee.com (ecobee specific security thing).
I found that my insteonplm binding was, like your first LOG experience, getting some values IN THE LOG but not displaying any.
Once I fixed ecobee (by the very ecobee-specific requirements of getting a new key from ecobee.com and applying) I got ecobee values. But this means the ecobee binding works fine - I just had a security issue.
But I still can’t fix insteonplm data and now eventually I get this error which worries me that my insteonplm binding is not compatible with OH2.
I wonder if your binding (DSCalarmBinding?) is broken in OH2 as I suspect mine is.
Error:
Exception in thread “Thread-36” java.lang.NoSuchMethodError: org.apache.http.impl.client.DefaultHttpClient.execute(Lorg/apache/http/client/methods/HttpUriRequest;)Lorg/apache/http/client/methods/CloseableHttpResponse;
at org.openhab.binding.insteonplm.internal.driver.hub.HubIOStream.getURL(HubIOStream.java:213)
at org.openhab.binding.insteonplm.internal.driver.hub.HubIOStream.bufferStatus(HubIOStream.java:108)
at org.openhab.binding.insteonplm.internal.driver.hub.HubIOStream.poll(HubIOStream.java:156)
at org.openhab.binding.insteonplm.internal.driver.hub.HubIOStream.run(HubIOStream.java:226)
at java.lang.Thread.run(Thread.java:744)
Exception in thread “/hub2/user:pwd@192.168.1.120:25105,poll_time=1000 Writer” java.lang.NoSuchMethodError: org.apache.http.impl.client.DefaultHttpClient.execute(Lorg/apache/http/client/methods/HttpUriRequest;)Lorg/apache/http/client/methods/CloseableHttpResponse;
at org.openhab.binding.insteonplm.internal.driver.hub.HubIOStream.getURL(HubIOStream.java:213)
at org.openhab.binding.insteonplm.internal.driver.hub.HubIOStream.bufferStatus(HubIOStream.java:108)
at org.openhab.binding.insteonplm.internal.driver.hub.HubIOStream.poll(HubIOStream.java:156)
at org.openhab.binding.insteonplm.internal.driver.hub.HubIOStream.write(HubIOStream.java:139)
at org.openhab.binding.insteonplm.internal.driver.hub.HubIOStream$HubOutputStream.flushBuffer(HubIOStream.java:308)
at org.openhab.binding.insteonplm.internal.driver.hub.HubIOStream$HubOutputStream.write(HubIOStream.java:302)
at java.io.OutputStream.write(OutputStream.java:75)
at org.openhab.binding.insteonplm.internal.driver.IOStream.write(IOStream.java:68)
at org.openhab.binding.insteonplm.internal.driver.Port$IOStreamWriter.run(Port.java:421)
at java.lang.Thread.run(Thread.java:744)
@kai mentioned that OH2b1 and on uses a backend that is more strict about variable declarations that OH1.x.
Maybe that is tripping up my insteonplm binding (and maybe yours).
I believe that in my setup (OH 1.8.0, JDK 1.7), the problem with the simple rule configuration was due to the ‘binding’ plugins not being available to the OH runtime,
In the demo configuration the ntp binding module is in the following location which I’m guessing isn’t read by the OH runtime classpath /etc/openhab/configurations/addons
By installing the binding via apt-get, the issue was resolved. I’m now working through the remainder of my items to make sure the bindings are available to OH runtime.
