I suspect the checks failed due to issues outside of this PR. The initial commit passed all checks. This one only has a README.md update, and spotless:apply locally does not change the file that was committed. How can I retry the checks for the PR, to get the necessary ticks?

Converted back to draft, as no ones assigned yet, to save adding another PR later on, for 2 more set's of devices. Please advise on the first question however - for future reference - looks like it fixed between checkin's.

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/vesync-levoit-binding-help-testing-requested/144175/18

@dag81 i might review this, but before that review, this PR has to build succesfull wihtout new SAT errors or warnigs. Can you sync your branches with openhab main, fix the conflicts and try to build it? Also the license headers should change to 2024.
If you need any help with those steps, please let me know.
Edit: Thing-upgrade instructison have to be added as some existings Things have channels added. See here: https://www.openhab.org/docs/developer/bindings/thing-xml.html#updating-thing-types

5. Thing upgrade instructions for the added channels are mandatory for this PR.

Hi @lsiepel, Hopefully this finds you well. I was just looking through this and testing on a M4 build against the device I have, I think this likely need's to be merged asap. So will limit the clean-up's to make sure we can hopefully get this in before the cut-off - as otherwise the units switch to % with the new units model for a few bits, as this binding is a old one and my first one. Looking at it I will likely do a deeper pass on it to fully clean it all up, but figured first and most importantly the key is to have it operating like the original binding did, several releases back.

Regarding the point I've quoted - can you give an example of a binding that has these, that I can use as a reference please?

5. Thing upgrade instructions for the added channels are mandatory for this PR.

Hi @lsiepel, Hopefully this finds you well. I was just looking through this and testing on a M4 build against the device I have, I think this likely need's to be merged asap. So will limit the clean-up's to make sure we can hopefully get this in before the cut-off - as otherwise the units switch to % with the new units model for a few bits, as this binding is a old one and my first one. Looking at it I will likely do a deeper pass on it to fully clean it all up, but figured first and most importantly the key is to have it operating like the original binding did, several releases back.

Regarding the point I've quoted - can you give an example of a binding that has these, that I can use as a reference please?

Reference to the documentation: https://www.openhab.org/docs/developer/bindings/thing-xml.html#updating-thing-types

homewizard is a binding that has these instructions.

The refactoring of this binding should be a seperate PR, als try to prevent breaking changes.

5. Thing upgrade instructions for the added channels are mandatory for this PR.

Hi @lsiepel, Hopefully this finds you well. I was just looking through this and testing on a M4 build against the device I have, I think this likely need's to be merged asap. So will limit the clean-up's to make sure we can hopefully get this in before the cut-off - as otherwise the units switch to % with the new units model for a few bits, as this binding is a old one and my first one. Looking at it I will likely do a deeper pass on it to fully clean it all up, but figured first and most importantly the key is to have it operating like the original binding did, several releases back.
Regarding the point I've quoted - can you give an example of a binding that has these, that I can use as a reference please?

Reference to the documentation: https://www.openhab.org/docs/developer/bindings/thing-xml.html#updating-thing-types

homewizard is a binding that has these instructions.

The refactoring of this binding should be a seperate PR, als try to prevent breaking changes.

Thank you @lsiepel :) Yeah definitely trying to avoid breaking changes overall :)

5. Thing upgrade instructions for the added channels are mandatory for this PR.

Hi @lsiepel, Hopefully this finds you well. I was just looking through this and testing on a M4 build against the device I have, I think this likely need's to be merged asap. So will limit the clean-up's to make sure we can hopefully get this in before the cut-off - as otherwise the units switch to % with the new units model for a few bits, as this binding is a old one and my first one. Looking at it I will likely do a deeper pass on it to fully clean it all up, but figured first and most importantly the key is to have it operating like the original binding did, several releases back.
Regarding the point I've quoted - can you give an example of a binding that has these, that I can use as a reference please?

Reference to the documentation: https://www.openhab.org/docs/developer/bindings/thing-xml.html#updating-thing-types

homewizard is a binding that has these instructions.

The refactoring of this binding should be a seperate PR, als try to prevent breaking changes.

I've opened the PR as Ready, I have just got to look through this and add these bits. I did this in case you wanted to check anything else, while I add this final bit, then its open and ready, to save to time going to and fro. @lsiepel

5. Thing upgrade instructions for the added channels are mandatory for this PR.

Hi @lsiepel, Hopefully this finds you well. I was just looking through this and testing on a M4 build against the device I have, I think this likely need's to be merged asap. So will limit the clean-up's to make sure we can hopefully get this in before the cut-off - as otherwise the units switch to % with the new units model for a few bits, as this binding is a old one and my first one. Looking at it I will likely do a deeper pass on it to fully clean it all up, but figured first and most importantly the key is to have it operating like the original binding did, several releases back.
Regarding the point I've quoted - can you give an example of a binding that has these, that I can use as a reference please?

Reference to the documentation: https://www.openhab.org/docs/developer/bindings/thing-xml.html#updating-thing-types
homewizard is a binding that has these instructions.
The refactoring of this binding should be a seperate PR, als try to prevent breaking changes.

I've opened the PR as Ready, I have just got to look through this and add these bits. I did this in case you wanted to check anything else, while I add this final bit, then its open and ready, to save to time going to and fro. @lsiepel

@lsiepel

I've had a first pass at the upgrade instructions file's. I will have to test them out over the next couple of days. (If its doing what I think that's really nice - I always hated having to say sorry just remote it and re-add then it should appear). In regards to these update scripts my "interpretation" which please correct if I'm wrong, is that the systems caching at a thing id level. So its applying these to its cache used for all defined devices, on boot up, to apply the updates so the channels / updates appear.

What I'm not sure about was the options bit. I've redefined it as I suspect it overwrites whatever it has based on what's defined, so the update to add the pet mode will add it once it runs?

Finally, a few channels types are re-used between two things. As my guess / interpretation is that the system duplicates the data for each thing the instructions are for, so if a typeId is re-used, this should be updated in every thing update definition, as its keyed to those thing's in the cache. Is this correct do you know?

I'll test anyway - but if you know the answers to above that would be great just to find out if its working how I suspect, in order to ensure those instructions have precisely what is required.

I think its ready for another pass now 🤞, so will change the PR status.

Hopefully you had a good weekend, and thanks for all the help in getting these PR's through, hopefully before the next release :)

@lsiepel this one is ready again when you are ready.