Item states in BasicUI

[megaoldgeek]

I am new to OH... I am not sure whats going on here for sure... yet ... but you asked if I had anything :) After initial discovery most devices states are null.. expected.. ( I don't have mapdb persistence on yet )

I can see the /state requests to the ST HUB for all items starting on line 984... triggered by me dropping my items files in the /conf/items/ directory... ~ around 19:00 hours... now at 21:00 hours the states look like the screen shot below..

Logs and items files attached (if that helps)?

So, a couple observations/questions here... 1) After the discovery I waited about ~10 minutes .. no /state requests... I assume this is because I had no items linked to the channels of these things? So on to item #2, add items :) 2) Who's triggering the /state on .items file changes? See line 984 onward... 3) Can your binding throttle it or can I? Maybe iterate / per capability every X seconds? 4) Most of the switches are not displaying the correct textual state or slider state. 5) The Basic UI goes blank when item #2 occurs... (aka all states seem to go null or -?) 6) I picked the first item from the Basic UI (highlighted) in screen shot.... Line 1606 of openhab.log says the binding changed it to state ON, yet it remains - in GUI

openhab.log events.log

OH_conf_files.zip

[megaoldgeek]

Don't know if this is related...

2018-01-15 21:44:16.986 [WARN ] [s.internal.SmartthingsHandlerFactory] - Unable to locate handler for display name: Office Sensor with attribute: humidity 2018-01-15 21:44:25.250 [WARN ] [s.internal.SmartthingsHandlerFactory] - Unable to locate handler for display name: Grandmas Bath Sensor with attribute: motion 2018-01-15 21:49:08.539 [WARN ] [s.internal.SmartthingsHandlerFactory] - Unable to locate handler for display name: Grandmas Bath Sensor with attribute: motion 2018-01-15 22:02:54.582 [WARN ] [s.internal.SmartthingsHandlerFactory] - Unable to locate handler for display name: Donnys Sensor with attribute: humidity 2018-01-15 22:02:54.582 [WARN ] [s.internal.SmartthingsHandlerFactory] - Unable to locate handler for display name: Donnys Sensor with attribute: humidity

[BobRak]

First of all - about the second message that starts "Don't know if this is related..." I looked at all of these devices in the discovery message you sent a while ago and for the most part they look like devices that only support a battery attribute. Can you shed more light on what they are. It doesn't appear they support the humidity or motion attribute. Also, in the SmartthingsInstallation document at the very bottom it talks about configuring the Smartthings App. Do you have that configured as you want. What the SmartApp really controls is which devices will subscribe to Smartthing Hub events and these get turned into state requests from the hub back to OpenHAB. For instance - if you have a switch that is included in the SmartApp config, and you physically change the switch a message will be generated in the hub and sent back to OpenHAB.

Now on to your list:

1. OpenHAB can send a /state message to the hub when it wants to know the state of a device. It will happen during startup and as part of completing discovery (I'm not all that much a discovery expert). The hub will respond with a /state message back to OpenHAB so the display can be updated. ALSO, as I said above, if you change a switch the hub will notice and will send a message to OpenHAB.
2. In openhab.log, right? These are coming from openhab as a result of doing discovery it wants to know the current status. When a new device is added OpenHAB sends a "refresh" command to the device handler. I then sends a /state to the hub to get the current state.
3. Are you asking if I can throttle the rate at which /state messages are sent? I could. It would be a big enhancement. Why should I do this?
4. Are they configured in the smart app?
5. Not sure why this is.
6. I don't know. I can look further.

I just want to let you know I'll look at things as my time permits. Right now my time is limited as I am trying to get my home of 23 years ready to sell. Like a full time job.

Bob

[megaoldgeek]

Thanks for the response Bob. No need to respond at all!
I'll respond in order and Ill close this as I think its my side or simply OH behavior. Live life , enjoy it, and thanks for your work on this binding its awesome!

To answer your requests before I close it off...

The devices in question are 4-1 sensors batter powered. Link here.. https://www.amazon.com/ZOOZ-Z-Wave-Sensor-temperature-humidity/dp/B01AKSO80O Yes, the SmartApp includes all of those sensors and they are initially discovered.

So I decided to create a simple TCP binding because this was driving me nuts and I only opened this request as you asked me to run your binding thru its paces before you submitted to OH. So, my binding is a brutal hack that simply listens on port 8090 and updates items states "if/when" they come in. Also hacked together a quick script I can run on the OH host to trigger state updates from the ST hub of any device or devices upon execution/demand.

Armed with this ... I reinstalled OH (as I did for your last snapshot) Restored the exact item/sitemap files I used for testing your binding. I found all of the behaviors observed with your binding could be observed with mine! So its either the way OH functions or some lacking in my config! So ... mute point.. as both eventually update in the GUI.

I don't see the "Unable to locate handler " log with my binding... Well doh! I know, I am not running your binding at the time. I only mention this because it could be the ST Hub spamming. As my TCP binding occasionally rejects state updates from the hub..

Which leads to why I asked about throttling... Its quite obvious (if you tail the logs) while spamming the hub with /state requests (up to 300 for me), with either with your binding or my hack the ST hub responds when it feels like it. Additionally I know its not sending a one for one response for the /state requests. I know this for a fact as I can spam from my script for all 300, get the 202s in response for all. Wait 24hrs and some of the devices still have a null state in the gui.

All said, this binding is rocking, I removed my hack and will create rules to spam /state so that OH updates when I want :)

Thanks again for this closing it out!