ok guys, i’ve finally been able to config my ASUKUKI for my needs, here is what i’ve been able to setup:
auto sync if the power/mode/light is changed using the physicall buttons;
water alert;
control mist speed (density) high/low;
turn it on always on my desired led color ( via automation );
still able to turn the rgb cycle mode on, brightness level or change the color via lovelace;
what i did:
1- flash tasmota using the blakadder GD-30W template.
2- use the blueprint to create the fan mode and water alert entities ( this worked without any change )
3- set my rules as below:
4- created an light entity with the code below (this is the entity used to control the desired RGB light and brightness)
5- setup lovelace card using:
the integration created from blakadder template to controle the fan on, modes and water alert
the device light trigger to control lights on/off (I isued this because i dont know how to make the entity ICON auto change to the rgb in use as the trigger does by default)
entity light to control brightness and new color
below is my end result:
rule1 on TuyaReceived#data=55AA000700056E040001007E do publish2 stat/difusor/EFFECT rgb_cycle endon on TuyaReceived#data=55AA000700056E040001017F do publish2 stat/difusor/EFFECT color endon on event#rgb_cycle do tuyasend4 110,0 endon on event#color do tuyasend4 110,2 endon on event#ON do tuyasend4 110,1 endon on event#OFF do tuyasend1 11,0 endon on power3#state=1 do tuyasend4 103,1 endon on power3#state=0 do tuyasend4 103,0 endon
rule2 on tuyareceived#dptype5id12 do publish stat/%topic%/error %value% endon on tuyareceived#dptype4id103==1 do publish stat/%topic%/fanmode high endon on tuyareceived#dptype4id103==0 do publish stat/%topic%/fanmode low endon
light:
- platform: mqtt
name: "LED DIFUSOR"
command_topic: "cmnd/difusor/EVENT"
state_topic: "tele/difusor/STATE"
state_value_template: "{% if value_json.POWER2 == 'ON' %}ON{% else %}OFF{% endif %}"
payload_on: "ON"
payload_off: "OFF"
retain: true
brightness_command_topic: "cmnd/difusor/Dimmer"
brightness_state_topic: "tele/difusor/RESULT"
brightness_scale: 100
brightness_value_template: "{% if value_json.TuyaReceived is defined and value_json.TuyaReceived['108'].DpId == 108 %}{{ value_json.TuyaReceived['108'].Type3Data[12:14]|int(base=16) }}{% endif %}"
availability_topic: "tele/difusor/LWT"
payload_available: "Online"
payload_not_available: "Offline"
qos: 1
rgb_command_topic: "cmnd/difusor/tuyasend3"
rgb_command_template: "{% set brightness = state_attr('light.diffuser_lamp','brightness') | int %}{{ '108,%02x%02x%02x646464' | format(red, green, blue)}}{{ '%02x' | format(brightness) }}"
rgb_value_template: "{% if value_json.TuyaReceived is defined and value_json.TuyaReceived['108'].DpId == 108 %}{{ (value_json.TuyaReceived['108'].Type3Data[0:2]|int(base=16),value_json.TuyaReceived['108'].Type3Data[2:4]|int(base=16),value_json.TuyaReceived['108'].Type3Data[4:6]|int(base=16)) | join(',')}}{% endif %}"
rgb_state_topic: "tele/difusor/RESULT"
Hey Tegots,
could you write a little more Detail? I have been working to get our diffuser locally integrated for a couple days now but it’s mostly not working (except the on/off).
What HA addons/integrations do you use?
Do you own the GD-30W or did you just use the template? I have the typical Asakuki of Amazon :-/
I tried to follow also and mine isn’t working correctly. Light is still only cycling colours, no brightness control and the fan speed doesn’t make the speed change (just on and off really). I also ended up with like 3 fan entities also so something is going wrong.
When you say flash using the template, assume you mean just flashing regular tasmota.bin then adding the template line from the top of the GD30 page into the diffusers config? But did you follow all those supplementary steps on his GD30 page under the configuration heading (the multiple backlog and rule 1 commands or skip those)?
What is the ‘integration created from blakadder template’?
yes, flash regular tasmota.bin then add the template line… then setup the MQTT (remember to change your %topic% ) and supplementary steps…
on the blakadder there is a blueprint that asks for you deffuser mac addres and %topic%… this blueprint will create an automation that will create the water sensor and fan entity with mist control
when you check the device configuration there will be more than 1 fan entity…the on you should use is the one created from the blueprint (you defined it’s name while setting up the automation blueprint)…this entity will have 2 preset speed modes (high,low)
there will be a new different entity (created by the code with the defined name “LED DIFUSOR” on my example and this is the one that should be used to fix the rgb color and change the color.
Thanks for the extra clarity. So here is where I am confused.
You created a light entity LED DIFUSOR and reference it in your card light.led_difusor… understood
But your card also has a second light entity called light.asukuki_light… where is this second light entity coming from? I only have one light entity, the one I added in configuration.yaml per your instruction.
I see my issue now. I had tasmota integration installed. I removed it along with all other config etc. to start from scratch with your instructions. I didn’t realise tasmota integration was replacing the old MQTT discovery so yeah wasn’t being discovered until I added the old setoption19 command. Now back to normal.
It actually seems to work and work well! You are a legend
One other issue I did have, I was adding fan and error sensor to configuration.yaml manually per the last part of the blakadder page - I’m realising now thats not needed as presumably the blueprint automation creates it directly.
I haven’t really used blueprints before. I assume I can now safely delete that automation?
The only thing I’d like to change is the turn on behaviour of the light, I never liked the cycling effect, I wish it turned on (from an off state) to solid colour and ideally the last defined colour. But guess can do that with an automation. I’m also not understanding why the usual colour picker (click on light bulb) is not allowing a static colour to be picked, it just keeps turning on the rgb cycle.
I’m super happy to have this damn thing working finally Thanks!
I believe the blueprint can be deleted but you need to keep the automation since it keeps tracking the mqtt log for the error trigger.
if you want you can use the manually created light entity (coded one) to trigger the light on/off with a solid color, I just didnt use it this way because i dont know how to make the “light bulb” from love lace keep track of the current color in use.
I took what you had and made some changes. I think I got it to work and does not require any additional mqtt entities that were auto created. In fact you should be able to delete them.
This requires the following:
SetOption19 to 0: Turn off MQTT auto discovery. This is to disable the mqtt light and switch entities from being created and reappearing if deleted.
SetOption4 to 0: Return MQTT response always as RESULT and not as %COMMAND% topic
SetOption17 to 1: Show Color as a comma-separated decimal string instead of hexadecimal. This is needed because the code from below uses decimal to report the state
SetOption59 to 1: Send tele/%topic%/STATE in addition to stat/%topic%/RESULT for commands State, Power and any command causing a light to be turned on.
I’ve just had a look to your ESPHome config on Github, very nice, thanks @sgvj!
I seen you put the code for out of water alert, does it finally work for you?
If it also work for a Maxcio 400ML diffuser maybe I’ll migrate from Tasmota. Because EspHome is now developed from Nabucasa
Not sure you told it, but why did you decide to stop using Tasmota?
I was the biggest fan of MQTT but now I avoid it as managing topics etc… feels like overhead when ESPhome is very plug and play. Tasmota also just feels odd, like it was designed to do something well and then got extended in unexpected directions. ESPhome was a framework from the getgo and the documentation is much easier for me to consume.
Water Alert, I think it works, right now I’m just confused about how/when it clears.
For the Maxcio 400ML diffuser, the water alert is switched off when you switch it on after putting some water inside if I understand correctly the point you mention.
You switch it on with water and when there is no water, the alert sensor is switched on and stays on until you switch the diffuser on again after you put some water.
After a switch on with water inside, the sensor switch to off again.
Hop this helps
A newbie question: why not using a binary sensor instead of a sensor in your ESPHome config?
EDIT : I asked about the error class, by reading better the documentation I found the answer to my question.
And using a binary sensor for water alert looks like possible and would allow to have it perfectly displayed in Home Assistant.
I have migrated one of my Maxcio 400ML diffuser to ESPHome.
I really feel understanding what I do with ESPHome more than with Tasmota, debugging is also simpler.
Lights are very basically implemented as I usually use the default behavior.
Just a bad point: the Maxcio 400ML diffuser has a strange behavior for DPId103 as it is 0 for low and 1 for high strength which is perfectly right, but when it is switched off it is set to 2.
I used a Tuya fan to set it up, so when it is switched off I had to use an internal sensor to switch the fan to off state but I still have the speed set to 3 so to 100% in Home Assistant.
And I did not found anything to force speed to 0.
If I don’t use this internal sensor, sometimes the fan stay to on even if it is off.
If I set the speed to 0 manually in Home Assistant the speed switch back to 100% so for Google Assistant for example, it is always on when it is off.
Impossible to specify only two speeds as it throws an error when DPId103 is set to 2.
With Tasmota I had the same issue and forced the state to off for Home-Assistant and speeds were set with modes so I had not the issue with speed.
I hop I will find a solution, else I will have to switch back to Tasmota.
If someone is interested or someone could find a solution, this is my config:
substitutions:
root: Office
sufix: office
esphome:
name: ${sufix}-diffuser
platform: ESP8266
board: esp01_1m
project:
name: "Nardol.maxcio_diffuser"
version: "1.0.0"
#web_server:
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_key
ap:
password: !secret ap_key
captive_portal:
api:
password: !secret api_pass
ota:
password: !secret ota_pass
uart:
baud_rate: 9600
tx_pin: GPIO1
rx_pin: GPIO3
# debug:
logger:
baud_rate: 0
level: NONE
tuya:
# Water sensor
binary_sensor:
- platform: "tuya"
name: ${room} Diffuser Water Alert
id: ${sufix}_diffuser_water
sensor_datapoint: 12
device_class: "problem"
# The diffuser
fan:
- platform: tuya
name: "${room} Diffuser"
id: ${sufix}_diffuser
switch_datapoint: 1
speed_datapoint: 103
speed_count: 3
# The internal turbo sensor to be sure the diffuser state is set to off even if DPID103 is set to 2
sensor:
- platform: tuya
name: ""
id: turbo
sensor_datapoint: 103
internal: true
on_value_range:
above: 2
then:
- fan.turn_off: ${sufix}_diffuser
# A very basic leds implementation
light:
- platform: tuya
name: ${room} Diffuser Leds
id: ${sufix}_diffuser_leds
dimmer_datapoint: 111
switch_datapoint: 11
min_value: 1
The @sgvj configuration give me the way to know more.
I think my config could be a good begining for an user who would keep the default behavior as possible.
Great work, thanks for sharing.
re: Binary Sensor - what you are doing makes sense, I would use this conditionally to show mist controls (I have a very minimal dashboard lovelace for control).
re: Tuya fan, I went and tried all the tuya components recently and came to the same conclusion. My solution is making my own switches from UART commands. Someone smarter than me could probably turn that into a template fan.
I like the way Blakadder made it so I wished to keep it as possible.
I used a binary sensor for mist strength internal only only to force the fan switching off but why not displaying it after all. In my case it would be too much things
A template fan would not be ideal for me as my goal is to show less things as possible in Home Assistant but it is the Tasmota approach.
Another way could be to create a speed fan with a template output so everything would be processed by ESPHome but I failed to do it.
And now Home-Assistant 2021.8 has come everything changed for me as Google Assistant report my diffusers as off when it is off even with the speed set to 100%.
So I can keep this as it is with no issue no problem if speed is set to 100% as the fan is displayed as switched off in Home Assistant.
And as I was very happy I used ESPHome homeassistant.service to send notification instead of an Home Assistant automation.
If it could interest some people, maybe I should create a Github repository with the ESPHome config and the little script I use to send an Android push notification with a tag when there is no water and to delete it when the diffuser is filled again.
I think mqtt light module is responsible for the problem you have using the color picker (or changing the brightness of the light). Every time a rgb_command_topic or a brightness_command_topic is sent, Home Assistant will send too a command_topic. This fires the RGB cycle in the diffuser.
To avoid this behaviour, I have created an automation. I have changed the command topic adding a sufix (for instance Gateway or GW) and the automation is triggered when this topic is sent, but only if the light status is the oposite of the command payload. So if the light was already turned on, the mqtt message will not be sent.
Is OTA flashing still unavailable? According to the wiki solderless jumpers are still the preferred method for flashing. Just confirming no new developments have been made.
no problem if speed is set to 100% as the fan is displayed as switched off in Home Assistant.