I just realised today that all my items of type color seem to be broken in some way. Could this be related to the upgrade to 3.1? It was working in M5 before.
What happens is the the items are not null but in a somewhat undefined state. They don’t get rendered correctly in the UI (see screenshot) and the items are not shown in the list when I want to link a thing channel to them.
Needless to say that rules that try to interact with these items fail but I have not seen a useful error message so far. I just says: failed to execute action.
This problem also occurs for newly created color items. I already cleared the cache and deleted persistence without any effect.
Did some more testing: Even when I spin up a new OH 3.1.0 container completely from scratch I observe the same behaviour: Color Items are broken. I don’t see how this could be related to the host machine (I used the same machine that hosts my productive OH instance) so it seems that at least the latest docker version seems to have a problem here. Can anyone confirm?
This is perfectly normal for a newly-created Item.
Same for any Item right after system reboot, unless you were expecting some persistence service to restore-on-startup some old value.
If it is linked to some channel/Thing/binding/device, you might expect that come along later and update it to something meaningful.
Perhaps the problem lies with the binding area.
The problem is that I cannot assign a value. The first example from production is linked to a channel that should provide a value. I tried to set a color manually through the UI but this does not work since the controls are not rendered at all
Okay, then you follow that through. What are the Thing status of the mystery binding? Does it log anything when you expect an update? Check both your openhab.log and events.log
I’ve just been having anunrelated conversation about UI widgets and NULL states, where it is not possible to make ‘undefined’ brighter or redder, say. I wouldn’t set much store by UI unresponsiveness at this stage.
Before I go through the logs let me share the following here. By using this script:
var hsb = new HSBType(new DecimalType(50), new PercentType(50), new PercentType(50))
events.postUpdate('bedroom_lamp_wardrobe_color', hsb);
I was able to give the color type item a value. However when I change the lamp color from outside of openHAB (through Mi Home app) the item state dissappears again. So this seems to be related to the miio binding. I’ll check out the logs now…
I did not find a lot, especially not in the logs. Let me sum up what I see in terms of unusual behaviour:
On OH startup I see an error that does not seem be related but it’s strange that a core bundle is reported missing:
2021-07-06 21:20:09.814 [ERROR] [Events.Framework ] - FrameworkEvent ERROR
org.osgi.framework.BundleException: Could not resolve module: org.openhab.core.config.discovery.usbserial.linuxsysfs [287]
Unresolved requirement: Import-Package: org.openhab.core.config.discovery.usbserial; version="[3.1.0,4.0.0)"
at org.eclipse.osgi.container.Module.start(Module.java:463) ~[org.eclipse.osgi-3.16.200.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel$2.run(ModuleContainer.java:1845) ~[org.eclipse.osgi-3.16.200.jar:?]
at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor$1$1.execute(EquinoxContainerAdaptor.java:136) ~[org.eclipse.osgi-3.16.200.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1838) ~[org.eclipse.osgi-3.16.200.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1781) ~[org.eclipse.osgi-3.16.200.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1743) ~[org.eclipse.osgi-3.16.200.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1665) ~[org.eclipse.osgi-3.16.200.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) ~[org.eclipse.osgi-3.16.200.jar:?]
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234) [org.eclipse.osgi-3.16.200.jar:?]
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:345) [org.eclipse.osgi-3.16.200.jar:?]
This does not happen in the test instance but as I said this seems to be related to a different binding.
Color items can no longer be controlled through the UI unless they have been initialised by different means (e.g. through a script). Not in production nor in a clean test instance.
I do not see any events from the miio binding in the logs when I control the lights from the Mi Home App. Consequently none of the lightbulb states are ever updated in OH. I recreated the thing (removed / readded) but that did not change anything.
Existing color items cannot be linked to thing channels as they do no longer turn up in the search results. However it seems as if there are more than just the color items missing, I do have about 250 items but the list seems to be way shorter than that. I can create new items starting from the thing channel but they remain in undefined state as well. This happens on the test instance as well. I only have one item there but it is not shown in the list.
I figured out that I can create links from the item to the thing channel (but not in the other direction).
So right now all channels except the color channel seem to be working as expected again.
The color channel however does only work from OH to the device (I can control the color from OH but changes through the cloud are not reflected in OH).
Moreover I noticed that even for the other channels I see no events in the events.log. Does the event log depend on the binding implementation or the binding log level?
events.log records changes to Item state. If a binding doesn’t get around to issuing state updates (that cause a change), there’ll be nothing to see.
Issuing commands to Items will usually invoke autoupdate and result in state changes via a fully internal path, such changes visible in events.log, plus usually the autoupdate prediction.
Autoupdate will be inhibited if it thinks the Item is linked to a broken channel (the supposition is that the command will fail). There’s usually an events.log prediction, but it is for “no change”.
Most bindings support a DEBUG logging mode, see docs
You might want to review the fiddly multicast stuff, too.
You might want to change thread title to attract more useful knowledge.
Thank you, for this information. Since e.g. the brightness channel does update my correspondig item I would have expected to see a change in the log.
Just for clarification: I use miio and not Mi Smart Home Binding.
Regarding the thread title: I think in the end there are multiple different topics here which are probably better adressed in separate topics like the miio binding color channel issue and the usbserial exception. I think I ran into this problem by deleting the persistence files (I had a different issue there). This led to the unitialized item states in the first place. I will observe what happens in the next couple of days and if I run into more problems I will start a new thread. Thanks again for your help!
People do get messed up logs. If you are convinced you have Item state changes that do not appear in your events.log, hunt that down before digging at anything else half-blind.
Ok you’ve got a point there. However I do not really know where to start: could this be a binding problem? Is my database corrupted? It could of course also be a mix of different problems…
Maybe I should tackle all these smaller issues one by one to see if this also solved my logging problems in the end?
EDIT: Just tried again to make sure that I wasn’t too tired yesterday night: In fact I do see events in the log for e.g. the brightness channel. So I guess the logs are fine, it was just me being to blind to see things…
Alright, with new confidence in your logging, what’s your summary of the problem?
Assuming it boils down to “my lamps don’t send status”, there is a “problems” section in the docs
which doesn’t look that helpful. It should be possible to put the binding into DEBUG logging mode to see if i notices incoming data.
I note that miio involves mdns, I think there have been framework changes in that area.
Remember nothing in this thread title will attract the interest of anyone knowing about miio.
What you would need to do here to better understand what is happening is to run the miio binding in debug mode. e.g. run in the consle log:set debug org.openhab.binding.miio
Then you should be seeing the refresh and possibly errors occurring.
I don’t recall any significant change to the colors processing in the last few months, so indeed interesting if anything broke
Ok right now I think it all boils down to two things that don’t seem right but also don’t seem to be related:
miio Binding: I do not receive colorRgb channel updates from the binding. @marcel_verpaalen thank you for joining in, I will try to debug this tonight and give you an update.
Background: Only after deleting my saved states I realised that I don’t receive any state updates from the thing since the item’s state remained null (I hardly ever use the cloud app to control the lights so it just did not come to my attention that it did not work this way round). I assume that the missing UI controls for color type items with a null-state are as designed. Initially I thought this was an issue but I maybe just never realised that it has always been like that.Since most of the time I would immediately link a newly created item to a channel I wouldn’t have noticed that.
Linking a thing channel to an item via Main UI: Opening an item and linking it to a thing works fine. The other way round (opening a thing and linking it to an item) however does not show a complete list of items to choose from. This also happens in a freshly installed instance (only 1 item & 1 thing → no item is shown at all to choose from). So this seems to be either:
a) a problem with Main UI or
b) a problem with the API
This information (what channels and types are available) is supplied by the binding “owning” the Thing. It’s likely about incomplete discovery by the binding. Don’t go off down a GUI rabbithole.
