@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.
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
[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?
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.
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.
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.
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.
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 = true does not work. openHAB does not post on the topic when I command the item. But, if the topic is $retained = true then 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.
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?
There should not have been any changes for a while now as I’m not able to debug the binding for the past month or so.
The binding uses 1.1.6 if I remember correctly, and you should not change away from the 1.1.x branch. Changing releases introduces changes to the API (which is quite normal - hence the version change). If you are using the 1.2.x branch, this will not work until the changes are merged - the changes are done, but I can’t properly test them at this time.
Correct, and I am using this one. I didn’t try upgrading to 1.2.x as I am waiting for the pull request to merge. I will revert back to M1 release as it was more stable.
If you are using 1.1.6, then it should work with the current snapshot and I’m not aware of any problems. I would really suggest that you find out what your problem is - reverting back to the older version will mean it does not get fixed, and when you upgrade to the next version the problem will still be there.
Actually I was running on a Snapshot build for a while and all devices where operating correctly, two days ago I updated the addons to the latest snapshot, then the problems started to show up. All my dimmers stopped responding and I found many exceptions in the logs.
My snapshot build was very old (something like 14xx). I think with all these changes to openhab since then, I will need to upgrade openhab fully and not only the addons.
I reverted back to M1 and everything is back online. I will wait until M2 to invest in upgrading.
Most likely M2 will be broken for you if no one fixes the issue you have with the current snapshot. And I guess since it works for most people, it‘ll not be possible to fix it without your help…
