Hi. You then tried the new esphome features in the oil diffuser?
Just got a Asakuki 500ml Oil Diffuser off Amazon (UK, £28) earlier this week and wanted to feed back how it went. I did the following:
- Convert to Tasmota by soldering (I followed this guide for a TYWE3S but didn’t need the NRESET), label on my board is “168YN2”.
- GD-30W Template and rules.
- Home Assistant config as per the above link.
- Modified Rule 1 and “on_command_type: brightness” for HA light YAML.
All seems to be working well from HA, I can turn mister on/off, adjust mister strength, turn light on/off, choose colour for the light. Haven’t tried the low water alert shut/off yet though.
Thanks for putting all this together and making it easy to follow
Interesting. Do you have the amazon link so I see if its the same as mine?
Curious, why solder? I’m sure I was able to flash mine over the air, wondering if I’ve used some other firmware, I’d love to get mine finally fixed.
Could I ask you how to edit the home assistant configuration.yaml for the fan. Yesterday I updated to the new version and some command of fan mqtt will deprecated: braking change
fan:
- platform: mqtt
name: "Diffuser"
availability_topic: "tele/GD-30W/LWT"
payload_available: "Online"
payload_not_available: "Offline"
state_topic: "tele/GD-30W/STATE"
state_value_template: "{{ value_json.POWER1 }}"
command_topic: "cmnd/GD-30W/POWER1"
payload_on: "ON"
payload_off: "OFF"
speed_state_topic: "tele/GD-30W/STATE"
speed_value_template: "{{ value_json.POWER3 }}"
speed_command_topic: "cmnd/GD-30W/POWER3"
payload_low_speed: "OFF"
payload_high_speed: "ON"
oscillation_state_topic: "stat/GD-30W/EFFECT"
oscillation_command_topic: "cmnd/GD-30W/EVENT"
oscillation_value_template: "{{ value }}"
payload_oscillation_on: "rgb_cycle"
payload_oscillation_off: "color"
qos: 1
speeds:
- low
- high
The following command will deprecated
speeds:
- low
- high
speed_state_topic: "tele/GD-30W/STATE"
speed_value_template: "{{ value_json.POWER3 }}"
speed_command_topic: "cmnd/GD-30W/POWER3"
payload_low_speed: "OFF"
payload_high_speed: "ON"
I know I have to use percentage command… but for some of that i don’t know … have you already did it?
Thanks
I have this and how you can read:
“Flashing via Tuya-Convert (OTA) seems to be no longer possible due to the PSK key issue”
For my device was mandatory solder =/ (It is a “new” version of the same product).
Amazon link
All the suppliers have started to put a new firmware onto their kit which makes it impossible to go via Tuya-Convert/OTA, I’m quite happy to solder so that was the easiest way forward for me. With the wires in place it’s pretty straight forward, plug in and Tasmotizer works straight away to backup the original firmware and flash the latest Tasmota in a couple of minutes. I’ve got it running off whatever the latest stable Tasmota is that Tasmotizer pulls automatically, scrolling up there were quite a few issues with older Tasmota versions so might be worth updating to the latest if you’re on an older version…
Thanks for the heads-up, I’m still on Core-2021.3.4 + OS 5.12 so not done the update yet…
Nice thats exactly the one I brought as it says last brought on the top. So I guess I am going at this project again
It worked but certain functions were not getting handled right in HA, I suspect it needed those rule tweaks but it was beyond my understanding. Maybe I was being lazy with it. But I’ll hopefully get chance to have a bash at flashing it again over the weekend with new vigour now I know there is an answer to the problem. Thanks for posting, no doubt I’ll be back later lol.
EDIT: finally I found the solution on this topic for all the logged messages thanks
Hello,
I have a Maxcio 400ML Aroma diffuser flashed with Tasmota using this link: GD-30W 300ml Aromatherapy Diffuser Template for Tasmota
But I simply cannot control the aroma diffusion.
When I switch the fan on, the button switches to off a second after I press it but the diffuser stays on.
The speed simply stays to “Off”.
It looks like json_value.POWER3
is nott reckognized, also JSON values for lights.
In the log, I have tons of:
2021-04-10 20:28:08 ERROR (MainThread) [homeassistant.helpers.template] Template variable error: 'dict object' has no attribute '108' when rendering '{% if value_json.TuyaReceived is defined and value_json.TuyaReceived['108'].DpId == 108 %}{{ value_json.TuyaReceived['108'].Type3Data[12:14]|int(base=16) }}{% endif %}'
2021-04-10 20:28:08 ERROR (MainThread) [homeassistant.helpers.template] Template variable error: 'dict object' has no attribute '108' when rendering '{% 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 %}'
2021-04-10 20:28:19 ERROR (MainThread) [homeassistant.helpers.template] Template variable error: 'dict object' has no attribute '108' when rendering '{% if value_json.TuyaReceived is defined and value_json.TuyaReceived['108'].DpId == 108 %}{{ value_json.TuyaReceived['108'].Type3Data[12:14]|int(base=16) }}{% endif %}'
2021-04-10 20:28:19 ERROR (MainThread) [homeassistant.helpers.template] Template variable error: 'dict object' has no attribute '108' when rendering '{% 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 %}'
I configured MQTT and set a MQTT topic and also the name and friendly name to have something less generic.
I used the provided Home Assistant configuration, changing the topic to match the one I configured (diffuseur_salon)
.
Here is my configuration:
tasmota_diffuseur_salon:
fan:
- platform: mqtt
name: "Diffuseur Salon"
availability_topic: "tele/diffuseur_salon/LWT"
payload_available: "Online"
payload_not_available: "Offline"
state_topic: "tele/diffuseur_salon/STATE"
state_value_template: "{{ value_json.POWER1 }}"
command_topic: "cmnd/diffuseur_salon/POWER1"
payload_on: "ON"
payload_off: "OFF"
speed_state_topic: "tele/diffuseur_salon/STATE"
speed_value_template: "{{ value_json.POWER3 }}"
speed_command_topic: "cmnd/diffuseur_salon/POWER3"
payload_low_speed: "OFF"
payload_high_speed: "ON"
oscillation_state_topic: "stat/diffuseur_salon/EFFECT"
oscillation_command_topic: "cmnd/diffuseur_salon/EVENT"
oscillation_value_template: "{{ value }}"
payload_oscillation_on: "rgb_cycle"
payload_oscillation_off: "color"
qos: 1
speeds:
- low
- high
light:
- platform: mqtt
name: "Leds Diffuseur Salon"
command_topic: "cmnd/diffuseur_salon/EVENT"
state_topic: "tele/diffuseur_salon/STATE"
state_value_template: "{% if value_json.POWER2 == 'ON' %}{% if value_json.POWER5 == 'ON' %}ON{% else %}OFF{% endif %}{% else %}OFF{% endif %}"
payload_on: "ON"
payload_off: "OFF"
brightness_command_topic: "cmnd/diffuseur_salon/Dimmer"
brightness_state_topic: "tele/diffuseur_salon/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/diffuseur_salon/LWT"
payload_available: "Online"
payload_not_available: "Offline"
qos: 1
retain: false
rgb_command_topic: "cmnd/diffuseur_salon/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/diffuseur_salon/RESULT"
binary_sensor:
- platform: mqtt
name: "Eau Diffuseur Salon"
state_topic: "stat/diffuseur_salon/POWER4"
payload_on: "ON"
payload_off: "OFF"
availability_topic: "tele/diffuseur_salon/LWT"
payload_available: "Online"
payload_not_available: "Offline"
qos: 1
device_class: problem
It is in a package, which is the reason of the unusual beginning.
The configuration is valid (only warnings about some configs which are now deprecated) but it is another story.
What dod I do wrong?
The GD-30W template is updated to provide speed percentage.
fan:
- platform: mqtt
name: "Diffuser"
unique_id: fan.diffuser
availability_topic: "tele/GD-30W/LWT"
payload_available: "Online"
payload_not_available: "Offline"
state_topic: "tele/GD-30W/STATE"
state_value_template: "{{ value_json.POWER1 }}"
command_topic: "cmnd/GD-30W/POWER"
payload_on: "ON"
payload_off: "OFF"
percentage_state_topic: "tele/GD-30W/STATE"
percentage_value_template: >
{% set forces_diffusion={"OFF":1,"ON":2} %}
{{ forces_diffusion[value_json.POWER3] if value_json.POWER1!='OFF' else 0 }}
percentage_command_topic: "cmnd/GD-30W/POWER3"
percentage_command_template: >
{% set forces_diffusion={0:"OFF",1:"OFF",2:"ON"} %}
{{ forces_diffusion[value] }}
speed_range_max: 2
oscillation_state_topic: "stat/GD-30W/EFFECT"
oscillation_command_topic: "cmnd/GD-30W/EVENT"
oscillation_value_template: "{{ value }}"
payload_oscillation_on: "rgb_cycle"
payload_oscillation_off: "color"
qos: 1
I tried to make it again as generic as possible because I did not named it GD-30W and the indentation is not really the same in my configuration so pay attention to the indentation and names.
Hop this helps.
Thanks a lot! It’s very helpful! However, I tried to use esphome… so I share the yaml file. It works a little bit (I’m noob and from this yaml is possible to control only turn on/off diffuser and turn on/off the light) but maybe it can help someone =)
esphome:
name: diffuser
platform: ESP8266
board: esp01_1m
# Make sure logging is not using the serial port MANDATORY!!!!!!
logger:
baud_rate: 0
wifi:
ssid: "XXXXXXXX"
password: "XXXXXXXX"
manual_ip:
static_ip: XXXXXX.X.XX
gateway: XXX.XXX.X.X
subnet: XXX.XXX.XXX.X
ap:
ssid: "XXXXXXX"
password: "XXXXXX"
captive_portal:
ota:
password: "XXXXXXX"
mqtt:
broker: XXX.XXX.X.XXX
username: XXXX
password: XXXXXX
web_server:
port: XX
uart:
baud_rate: 9600
tx_pin: GPIO1
rx_pin: GPIO3
tuya:
switch:
- platform: "tuya"
name: "Diffuser_Switch11"
switch_datapoint: 11
- platform: "tuya"
name: "Diffuser"
switch_datapoint: 1
sensor:
- platform: "tuya"
name: "Diffuser_13Enum"
sensor_datapoint: 13
- platform: "tuya"
name: "Diffuser_14Int"
sensor_datapoint: 14
- platform: "tuya"
name: "Diffuser_103Enum"
sensor_datapoint: 103
- platform: "tuya"
name: "Diffuser_108StringValue"
sensor_datapoint: 108
- platform: "tuya"
name: "Diffuser_109Enum"
sensor_datapoint: 109
- platform: "tuya"
name: "Diffuser_110Enum"
sensor_datapoint: 110
- platform: "tuya"
name: "Diffuser_111Int"
sensor_datapoint: 111
This works for this device: that is similar GD-30W 300ml
It’s very important set:
logger:
baud_rate: 0
To check the GPIO see the tasmota template of your device.
To check datapoint you can check when you flash the firmware the log /console and it reports thanks to
" tuya: " all the datapoint of that device.
Has someone solved the not updated water sensor?
On my side it is the only remaining issue
I think I’ll propose some updates for the Home Assistant configuration provided in the GD-30W Blakadder template.
As it looks like to be the best reference template for smart oils diffusers it could be good to make it the most updated as possible.
I’m at the same stage where everything else works apart from the l"ow water level" alert sensor. I’ve been monitoring the Tasmota console on verbose logging for the exact moment when the water runs out:
16:27:41.587 TYA: Send “55aa00000000ff”
16:27:41.599 MQT: tele/mister_1/RESULT = {“TuyaReceived”:{“Data”:“55AA010000010102”,“Cmnd”:0,“CmndData”:“01”}}
16:27:41.626 TYA: Heartbeat
16:27:43.241 WIF: Checking connection…
16:27:52.583 TYA: Send “55aa00000000ff”
16:27:52.600 MQT: tele/mister_1/RESULT = {“TuyaReceived”:{“Data”:“55AA010000010102”,“Cmnd”:0,“CmndData”:“01”}}
16:27:52.628 TYA: Heartbeat
16:27:59.718 MQT: tele/mister_1/RESULT = {“TuyaReceived”:{“Data”:“55AA010700050C050001011F”,“Cmnd”:7,“CmndData”:“0C05000101”,“DpType5Id12”:“0x01”,“12”:{“DpId”:12,“DpIdType”:5,“DpIdData”:“01”}}}
16:27:59.748 TYA: fnId=14 is set for dpId=12
16:27:59.754 MQT: tele/mister_1/RESULT = {“TuyaReceived”:{“Data”:“55AA0107000501010001000F”,“Cmnd”:7,“CmndData”:“0101000100”,“DpType1Id1”:0,“1”:{“DpId”:1,“DpIdType”:1,“DpIdData”:“00”}}}
16:27:59.784 TYA: fnId=11 is set for dpId=1
16:27:59.787 TYA: RX Relay-1 → MCU State: Off Current State:On
16:27:59.789 SRC: Switch
16:27:59.798 MQT: tele/mister_1/STATE = {“Time”:“2021-04-09T16:27:59”,“Uptime”:“0T21:12:28”,“UptimeSec”:76348,“Heap”:26,“SleepMode”:“Dynamic”,“Sleep”:10,“LoadAvg”:99,“MqttCount”:5,“POWER1”:“OFF”,“POWER2”:“ON”,“POWER3”:“ON”,“POWER4”:“OFF”,“POWER5”:“ON”,“Dimmer”:100,“Fade”:“OFF”,“Speed”:1,“LedTable”:“ON”,“Wifi”:{“AP”:1,“SSId”:“nr18_2.4”,“BSSId”:“2C:3A:FD:C2:05:25”,“Channel”:11,“RSSI”:94,“Signal”:-53,“LinkCount”:4,“Downtime”:“0T00:00:07”}}
16:27:59.811 MQT: stat/mister_1/RESULT = {“POWER1”:“OFF”}
16:27:59.816 MQT: stat/mister_1/POWER1 = OFF
16:27:59.822 MQT: tele/mister_1/RESULT = {“TuyaReceived”:{“Data”:“55AA010700050B0100010019”,“Cmnd”:7,“CmndData”:“0B01000100”,“DpType1Id11”:0,“11”:{“DpId”:11,“DpIdType”:1,“DpIdData”:“00”}}}
16:27:59.849 TYA: fnId=12 is set for dpId=11
16:27:59.851 TYA: RX Relay-2 → MCU State: Off Current State:On
16:27:59.854 SRC: Switch
16:27:59.863 MQT: tele/mister_1/STATE = {“Time”:“2021-04-09T16:27:59”,“Uptime”:“0T21:12:28”,“UptimeSec”:76348,“Heap”:26,“SleepMode”:“Dynamic”,“Sleep”:10,“LoadAvg”:99,“MqttCount”:5,“POWER1”:“OFF”,“POWER2”:“OFF”,“POWER3”:“ON”,“POWER4”:“OFF”,“POWER5”:“ON”,“Dimmer”:100,“Fade”:“OFF”,“Speed”:1,“LedTable”:“ON”,“Wifi”:{“AP”:1,“SSId”:“nr18_2.4”,“BSSId”:“2C:3A:FD:C2:05:25”,“Channel”:11,“RSSI”:92,“Signal”:-54,“LinkCount”:4,“Downtime”:“0T00:00:07”}}
16:27:59.876 MQT: stat/mister_1/RESULT = {“POWER2”:“OFF”}
16:27:59.881 MQT: stat/mister_1/POWER2 = OFF
16:27:59.053 CFG: Saved to flash at FA, Count 178, Bytes 4096
16:28:03.241 WIF: Checking connection…
16:28:03.586 TYA: Send “55aa00000000ff”
16:28:03.602 MQT: tele/mister_1/RESULT = {“TuyaReceived”:{“Data”:“55AA010000010102”,“Cmnd”:0,“CmndData”:“01”}}
16:28:03.631 TYA: Heartbeat
It looks like the bottom two bits to turn off POWER1 and POWER2 work ok, there’s a line above those for “fnId=14 is set for dpId=12” which seems to be the part that maps the low water error to relay 4 but the relay doesn’t seem to change state.
The TuyaMCU manual has a bit more info on aromatherapy machines. My suspicion is that this isn’t working because DPID12 (<- the fault alert) is a function type = error rather than a boolean and comes through as “DpIdType”:5 rather than “DpIdType”:1 on the two working commands? I don’t know enough about Tasmota though to get much further… happy to help with testing or get more details if somebody can help with the Tasmota side
My knowledge are also poor about Tasmota but there is another point which lets me interrogative.
Is there an way to know when there is water again?
I also noticed some events when there is no water but I did not notice something to be sure when there is water.
Or on the HA side, are there some MQTT events thrown?
For information, I updated the GD-30W Tasmota template to reflect changes I noticed in this topic.
Feel free to tel me if I forgot something or if there is some mistake, I’ll made another pull request or make your own PR if preferred no problem.
I’ve had a bit of spare time this morning so had a closer look into Tasmota (this post was pretty useful), a lot of it seems to work in a certain way so we don’t get much choice over what it does behind the curtain but I’ve found a way that seems to work.
The error get’s thrown when the water level is low, there seems no easy way to use that for a relay and there is no “error off” type command coming through once refilled either. What does happen is that once the error get triggered the whole unit turns off, once turned on it checks for water level and if still low it turns off again.
Rule 1 let’s us add more logic to send MQTT messages for certain TuyaReceived messages, I’ve hence added:
on TuyaReceived#data=55AA010700050C050001011F do publish2 stat/mister_1/WATER ON endon ← This sends when the water level error comes up.
on TuyaReceived#data=55AA01070005010100010110 do publish2 stat/mister_1/WATER OFF endon ← this sends when the unit get’s turned on.
I’ve tried it and it works ok for me, once the water runs out the unit goes off and in HA I get the error state. If I turn the unit back on without refilling the water state goes back to normal but gets reset to the error state a second later as the unit turns back off. Once refilled the unit turns back on, runs and the error stays reset to off. It’s a bit clumsy but very much reflects what the unit does in reality.
The new Rule1 I’m using is:
Rule1 0
Rule1 on TuyaReceived#data=55AA010700050C050001011F do publish2 stat/mister_1/WATER ON endon on TuyaReceived#data=55AA01070005010100010110 do publish2 stat/mister_1/WATER OFF endon on TuyaReceived#data=55AA010700056E040001007F do publish2 stat/mister_1/EFFECT rgb_cycle endon on TuyaReceived#data=55AA010700056E0400010180 do publish2 stat/mister_1/EFFECT color endon on event#rgb_cycle do tuyasend4 110,0 endon on event#color do tuyasend4 110,1 endon on event#ON do backlog tuyasend4 110,1 ; tuyasend1 11,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
Rule1 1
I’ve modified the MQTT low water sensor to listen to stat/mister_1/WATER, probably don’t need the RELAY4 related Tasmota code anymore with this but not taken it out yet.
I’ve also updated the HA config to the new template which works ok, only one thing is slightly irritating… I tend to set it to a static colour and when I turn the unit back on the oscillation always comes back on, once I turn oscillation back off it nicely goes back to the colour I set before but it would be nicer if it could remember the oscillation setting it was on. Is there a way to make it remember the last oscillation state or set it to “default = off”?
Thanks a lot!
Is there a reason to have modified the rule1 and not created another dedicated rule for the water sensor?
I understand you added the water sensor to this rule because this is the rule which publishes MQTT states but as it is for another domain I would suggest to make a separate one.
Looks like not to make any difference after testing but I would like to be sure.
About oscillating state: for me it is off by default but my Rule1 is the one provided in GD-30W template which differs from yours.
And the default behavior is the one you describe.
I edited my previous message as I forgot some important points.
For the oscillating state, maybe you could use an automation to turn it off when the fan is switched on?
No particular reason behind me putting the code into Rule1, a separate rule would indeed be tidier.
I think I adopted the slightly different Rule1 from a comment a bit further up when I couldn’t get the RGB cycling to stop, does everything work ok with the code in the template for you? If that doesn’t work out I’ll follow your suggestion of an automation
You are right, in fact I did not pay any attention to lights and they did not work as expected So with your rules all is OK.
So the definitive light and water rules for me are:
Rule1 0
Rule1 "
Rule1 on TuyaReceived#data=55AA010700056E040001007F do publish2 stat/GD-30W/EFFECT rgb_cycle endon on TuyaReceived#data=55AA010700056E0400010180 do publish2 stat/GD-30W/EFFECT color endon on event#rgb_cycle do tuyasend4 110,0 endon on event#color do tuyasend4 110,1 endon on event#ON do backlog tuyasend4 110,1 ; tuyasend1 11,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
Rule1 1
Rule2 0
Rule2 "
Rule2 on TuyaReceived#data=55AA010700050C050001011F do publish2 stat/GD-30W/WATER ON endon on TuyaReceived#data=55AA01070005010100010110 do publish2 stat/GD-30W/WATER OFF endon
Rule2 1
Maybe I take too much precautions when (re)defining rules by deleting them after disabling but I prefer to be sure all is as expected before.
Thanks again, now you found how to solve the water sensor issue all is perfect!
For your information, instead of publishing to MQTT, you can set the switch to on/off by using power4 1
to switch it on or power4 0
to switch it off.
Doing so, we follow what is specified.