Yes, and I looked both in Habmin & Paper UI. I also tried restarting the binding & OH. Most of my device data in the DB should have been the same.Perhaps the XML files changed slightly between snapshots.
No - the files don’t tend to change unless someone updates the database. It’s unlikely that all your devices would have been updated, and even if they were, it should not matter as the format is the same - it hasn’t changed for many years.
1 Like
Strange - maybe for some reason the ZWave binding starts faster or earlier or something. I’m not sure, but I really can’t see how the binding can impact this as it’s the serial driver that returns the error.
I don’t think anything has changed in the binding for quite a while (many months) in this area. At the moment I’m not even in a position to develop and test the binding for the past month due to IDE issues.
My guess is that this is possibly a timing issue and something has changed in your system that has changed the startup timing. (again, that’s just guesswork).
Sure, that’s gonna be a whole lot of fun when all those openHABian users on OH 2.5.0.M1 open the openHABian-config tool and select option 2 “Upgrade system” and all of a sudden ‘everything’ is broken. The same for all the linux users when the issue sudo apt update && sudo apt upgrade.
Did you forget the mess that was caused by the MQTT v2 binding with the release of OH2.4.0? That was only one binding and it was unexpected. Now you want to intentionally break many peoples system?
1 Like
I could probably have phrased that better. What I was trying to say is that since it has been quite some time we have had a new release (minus the nightlys) lets make sure it’s as functional as it can be.
2 Likes
@Kai My appologies, you are correct about the JuPnP in M2. Apparently it was upgraded prior to M1, I just did not hit the issue until moving from M1 to the new nighties. Please see Too much time before a Sonos thing becomes definitively ONLINE as I believe it is the same issue. I will open a github issue so it can be tracked properly.
@shutterfreak I’m not sure I understand your statement about the compiling. I completely would agree that if the rules file itself was somehow altered that it would have to recompile. Otherwise the only time I update the files is if I change the code logic itself.
I think he’s referring to the fact that rules must be internally compiled which happens when they’re called for the first time (after that the bytecode result is cached and reused unless you provide too few memory to JVM for storage). This will result in noticeable delay on first execution of a rule (noticeable only on slow machines like RPi). But that’s a one-time thing, second and further runs are fast.
Your problem is different as your “add to queue” calls seem to act like blocking calls (due to whatever recent changes). Just a quick maybe useless idea: could it be the say command to block access to all sinks ? Replace say with Thread::sleep or similar for a test.
yes… probably
That’s an interesting idea. I had not considered the say command itself as a blocking item. I’m not why it would block rules in a different file though. My understanding is that (very roughly) each rule file is run as a separate thread. If that’s true, and assuming I don’t have thread exhaustion which I’m not seeing evidence of, I don’t know why one would block the other. Thoughts? I’ll test with thread sleep later.
So according to your statements the following issues should be added to the list:
- Hueemulation (<- Couldn’t find a concrete issue. In the first post a search is linked which is quite unconcrete as none of the issues sound like it makes hueemulation ‘completely unuseable’)
Person that can solve best: @David_Graeff - Zwave (#1178, #1195)
Person that can solve best: @chris - Caldav (#5870)
Person that can solve best: Michael Wodniok
Furthermore still open on the list is:
- [Automation] Paper UI (JSON) rules fail to load after ESH reintegration (#674)
Person that can solve best: @5iver (according to your post in this thread) or Ben Clark
Is that the list for M2? If so could some maintainer add it to the tracking?
Sorry, but as above, I’m unable to do anything with the ZWave binding until the IDE issues are resolved.
3 Likes
Correct. For hueemulation, the latest issue from @goofy79 sums it up… no Items are discovered. I’ve also created one for the fact that, once discovery actually works, ALL Items will be discovered unless the user has tagged every Item that they don’t want to be exposed to Alexa.
As for #674, Kai has asked Ben, who has done similar scripts like this in the past, for a PR.
1 Like
Thanks @bjoernbrings for the summary - I have added those issues to https://github.com/openhab/openhab-distro/projects/2 now.
Understood, but I hope we’ll soon be there and we will clearly wait with the M2 build until you had time to look into those issues and hopefully fix them.
1 Like
@Kai,
I want you to know that the dedication of you and your developers is very appreciated. Your attention to detail is especially refreshing.
4 Likes
As a user my major issue is that MQTT homie support was broken in 2.4 but cited as fixed in 2.5M1. When it was found to be still broken in M1 it was cited that some fixes had just missed the build and M2 would be required. Now it’s known that the MQTT issues are deep rooted and not fixed.
I, and several others have wasted days and days of time in trying to get homie working ready for the M2 release. Trying to enhance OH import compatibility with other systems.
Having said that we need a new milestone release and as MQTT can’t be fixed in time I suggest this is marked as an outstanding known issue with M2 and it goes ahead.
What I am somewhat aggrieved about is that I think the MQTT issues have been known for sometime but not addressed and that users like myself have been led to believe it was all fixed for M2. Indeed if it had been addressed when discovered maybe it would have been fixed in time for this M2.
1 Like
Please point me to the most important homie issues. I‘ll try to improve that within the next week (I don‘t use it, so my idea what is severe and what is not is very limited).
@leif, I think your threads on MQTT 2.5 M1 and Homie are the most comprehensive in discussing the problems with supporting Homie. I’ve lost them in the shuffle. I think the biggest issue is that periodically the Homie Thing will go offline or encounter some other error which will bring down all the Things including Generic MQTT Things.
1 Like
Exactly right. Whenever a Homie device goes offline (or perhaps it’s when you change the Device ID of a homie thing?) all subscriptions of all other MQTT things on that binding (whether generic MQTT or Homie, I have not tested others) on that same broker connection thing seem to have their subscriptions cancelled. Disabling and re-enabling the broker connection thing makes it work again.
@J-N-K, here are the threads. Thank you for asking!
Here are some more things I have discovered since then which I haven’t posted about because of the “bigger fish to fry” factor, but posting now just in case.
- It would be nice if when you add a new Homie thing, the displayed name in openHAB came from the $name property instead of the last subtopic.
- Commanding a new value to a homie property that is not
$retained = truedoes not work. openHAB does not post on the topic when I command the item. But, if the topic is$retained = truethen openHAB properly sends a message on the topic when you command an item associated with it. This means I have make even pure command topics retained just to get them to work, even though it makes no sense that a command like “OPEN THE GATE” should be retained – it’s a message, it’s only valid once! It could be that I’m misunderstanding something.
Can you please post the github link, I have reported that issue and would like to stay up-to-date regarding the status, thank you!
Hi @chris
I think the latest snapshot build of the Zigbee binding has some issues. I keep getting exceptions from zsmartsystems lib and my bulbs are not responding. Which version of zsmartsystems is compatible one at the moment?