Support Levoit Core200s (WIP, Feedback requested)

[blenk92]

Description:

Hi there, I bought one of these devices https://levoit.com/collections/air-purifiers/products/core-200s-smart-true-hepa-air-purifier and figured that is uses a esp32 (the solo1 variant) to talk to another MCU via a serial protocol. I've reversed the protocol (well at least the relevant parts I would say) to control the air purifier using Tasmota.

This PR contains my initial implementation, to proof that its generally possible to that (so its still kind of in a POC state in some places). However, it should already give a rough idea on how the protocol works... However, before I spend additional efforts in making it better, I would like to request some indication if the project would generally be interested in support these devices. I say 'these' because Levoit offers a bunch of similar devices, I only own a Core200S but I could imagine that other models are similar, maybe even using an extended version of the protocol (and there are still some fields in the status messages that seem to be unused on my device).

Since this is quite a large patch already, I would also like to ask what else I would need provide in order to get the levoit devices (ore at least the core200S) officially supported.

Screenshot to show you how the web interface currently looks like:

Related issue (if applicable): fixes #

Checklist:

• [X] The pull request is done against the latest development branch
• [X] Only relevant files were touched
• [X] Only one feature/fix was added per PR and the code change compiles without warnings
• [ ] The code change is tested and works with Tasmota core ESP8266 V.2.7.6
• [X] The code change is tested and works with Tasmota core ESP32 V.3.0.0
• [X] I accept the CLA.

NOTE: The code change must pass CI tests. Your PR cannot be merged unless tests pass

[barbudor]

Hi @blenk92 As this device is based on ESP32, have you considered a Berry driver instead of a native one ? I think it could make more sense

[blenk92]

Hi @blenk92 As this device is based on ESP32, have you considered a Berry driver instead of a native one ? I think it could make more sense

Hi @barbudor,

actually, I didn't. Seems like I missed that option completely. Thanks for the hint, will check it out later today.

[blenk92]

Hi @blenk92 As this device is based on ESP32, have you considered a Berry driver instead of a native one ? I think it could make more sense

Hi @barbudor,

took me a bit to work myself into berry, but I think you have a point here. I re-implemented the current state in berry (the original change with the native driver is still available at https://github.com/blenk92/Tasmota/tree/core200s_native for reference)

Please let me know how we can proceed to get this merged ;-)

[barbudor]

Great @blenk92

Merge is not under my control. May be it could be worth adding along a Core2005.md doc along to explain how to use the driver, any configuration etc...

[arendst]

@s-hadinger is this a good implementation of a compiled-in berry driver? I had hoped this functionality could be added by users during runtime keeping the binary small ...

[Jason2866]

@s-hadinger is this a good implementation of a compiled-in berry driver? I had hoped this functionality could be added by users during runtime keeping the binary small ...

The driver is loaded at runtime by the user. It is not solidfied. So no code size increase when not explicit loaded. Imho nice implementation when the few things Stephan reviewed are fixed.

[arendst]

OK. I leave it to @s-hadinger then 👍

[blenk92]

Thanks, there are some changes needed, primarily remove the long delay() (above 50ms) and do async with tasmota.set_timer() instead.

You can also consider packaging all these in a single module, and avoid polluting the global namespace.

Thanks for you review. I tried to adapt according to the comments that you left. There is maybe still something open in regards of the async behavior. Maybe you want to have another look ?

Just FYI: I won't have access to my Core200S for ~ 1.5 weeks. So no hurry with the re-review, because I can't test potentially requested changes on my device until then...