[WIP] Summarizing the identified issues from both Milestone Testing threads: M6 & M7:
If you have identified some extra stuff that I missed (from the forum or github), please reply here with a link to the relevant forum post. They need to be: (i) bugs (not config mistakes due to vague docs) & (ii) reproduce-able.
I haven’t listed the ones that were already fixed (e.g. PR#6638 & PR#4324, PR#6583 and many others)
My (personal) conclusions:
No (red hot) blocking issues that are going to be carried over to 2.4.0 Stable Release
It is critical to communicate effectively the way to handle the breaking changes when upgrading from <2.3.0 to 2.4.0 (e.g. Z-Wave, etc). Not only to inform about them, but also instruct how to overcome them.
Short overview of identified issues in the table below:
What I have seen so far (it was hard to re-read both threads and cut through the “noise” of troubleshooting )
I recently discovered that MilightV3 bridges do not work anymore since @David_Graeff’s Spring Cleanup. Unfortunately, I had completely no time when I saw it and rolled back immediately without saving log files I’ll try to reproduce it tomorrow and open an issue. (Yes, I saw that the thing type IDs changed and considered that in my config)
EDIT: It could be #4232. If we keep Davids changes, we should point out the changed thing type IDs and the known issues with V3 bridges within the Changelog.
I’ve created an Eclipse Smart Home issue (6649) for issue 1 mentioned in the list above. My first guess is it might not be a blocking issue, but it needs to be researched why this message is given.
Regarding Milight: For me, also the first V3 bridge did not work because the client port used by the binding is already occupied on my Raspberry with a Milight emulation service. Anyhow, the current implementation also prevents the usage of mulitple bridges. Also, the discovery service does not work anymore after adding the first bridge.
Submitted #4341 to fix this (it includes resolution of #4232). Would be good to get it merged before the release.
My plan would be to go for M8 tomorrow. We had quite some stuff merged this weekend, but most activity is on fixing add-ons and not so much on the core runtime, which we should keep stable as much as possible.
Now my finding is: *_1_ACTUAL_TEMPERATURE receives it’s initial value from persistence but changes to UNDEF with the first update from the CCU3. Is this item definition wrong?
The Hue Emulation is/was missing the XY implementation, I’ve proposed a fix in the comments of the PR. As far as I remember the Logitech Harmony needs those to work correctly, definitely my Ambilight-TV does. Would be great if we could get this merged before the release, I’d say that even an not-well-tested implementation is better than no implementation of that part at all. I’m truly amazed by my ambilight TV now using all lamps in the room, sitting in there now is just great.
Yesterday I did some testing with 2.4 M8. I have a rock solid 2.3 installation with several bindings. Mainly homematic via piVCCU (CCU2 version), mysensors, mqtt espmilighthub which also utilizes mqtt for communication with things. I have OH and piVCCU running on an orange pi +2e with armbian 5.60.
I wanted to start with piVCCU3 so I need the new binding which is part of OH > 2.4 m5. For the upgrade of OH I used the testing repository. Installation went fine, I had to delete my homematic things as the new binding expects the thing definition slightly different, so I let the binding discover. I also had to install the new mysensors binding from IOT market. so after an hour everything worked fine. I cleared the cache and tmp, restarted, all things came up. I was able to send new setpoints to the heating controllers which delivered all temperature measures. Very smooth migration. But after another hour without any additional interaction (I wasn’t at home for a while) openhabs event engine stopped working. I could open the web interface but all values are old, no control of heat controllers, no light switching. Bam. I restarted openhab but same thing after a while (20 min to about an hour). No error log, nothing, which makes it really difficult to analyze. Anyway, any ideas?
But I think this is really a serious problem.
@joga As I am not aware of anybody else’s report of a similar problem, I would expect some binding to be the culprit (although I agree that it should not be possible to stall the whole runtime through a faulty binding).
I think the only way to analyse it is to figure out, which binding causes it, so you might want to remove (or add) them one by one. I’d start with the mysensors as this is not part of the official distro, but comes from the marketplace.
@Kai Thanks for your answer. I will follow your suggestion and disable all bindings and make a new start with homematic and mqtt as these are most important for me. I will report.
just switched to OH2.4.0-M8 and gave a quick shot to HABot. HABot is quite impressive but the results are most often not very readable. Any chance to improve this for the final release?
On my Android Smartphone the actual numbers aren’t even visible!
The screenshot is taken on a MacBook running Windows 10 and Firefox 63.0.3.
@joga It could also be that the threads get into deadlock. So maybe you can also provide us with some detailed thread information next time the issue occurs?
To get the thread info you can issue the following command on the Console:
)
I’ll try to reproduce it tomorrow and open an issue. (Yes, I saw that the thing type IDs changed and considered that in my config)