-
Notifications
You must be signed in to change notification settings - Fork 839
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Samsung AC - "Clean" automatically gets toggled by the AC unit #2006
Comments
What you're describing is really beyond the scope of the library. We aim to provide the ability to send every kind of message we can to an A/C, but the library can't/won't provide complete emulation of a remote for an A/C. We do our best to emulate where we can, the intended operation of a remote (e.g. Toggle Controls) but a value that changes over time. e.g. Clocks, cleaning state, timers, Sensor temps, etc. are strictly in the realm of the program using this library (or at an even higher level), not the library itself. Basically, this library offers a programmer the tools to write a full emulation or what ever they want, by sending the messages to the A/C for them. We can't add automatic features without it potentially affecting someone elses use of the library. By keeping this simple, predicatable, & low-level we offer the greatest possible use cases for developers/programmers/users. I suspect the Tasmota folk will give you a similar response. You're asking for a higher-level feature than what they are offering via their api/service. For instance, this is something that should be done by your home automation system. Note: Tasmota uses our generic A/C API/interface ( Hopefully I've explained it well, and I'm assuming understanding your question/problem/predicament correctly. Please let me know if I've got it wrong. |
You are correct, and I will admit I half expected this answer. And yes, I do expect Tasmota to be similar - but at the same time, I need a way to change the internal state of the system without causing a new IR signal to be sent. And I could do that if only one of the components in the chain ( HomeAssistant, the In this particular case, I need a way to do exactly this: "Your home automation system should set/toggle/what-ever the "clean" setting; cause the message to be sent; then 15 mins later, reset/change/toggle/etc the "clean" setting". WITHOUT sending an IR signal. And I thought that was not possible - but looking at the links you posted (thank you!!), it appears that the library supports this (or at least IRSamsungAC seems to support it, via For now, I will close this. Thank you so much for the very detailed reply! And once again, a big thank you for all the work you are doing on this library - it has helped me more times than I can count!! |
To correct the record, IRRemoteESP8266 does allow that, both via the
Line 2235 in 8082175
& Line 2265 in 8082175
The IRac my_ac(GPIO_PIN);
...
my_ac.next.clean = true; // Set the internal state of my IRac object's clean setting to On, but don't actually send it.
...
// Now that I'm ready, send the desired state to the A/C.
my_ac.sendAc(); However, I suspect the way Tasmota is using it, they are not using or exposing that approach, and to be honest, 99.99% of the use cases are catered for using the simpler interface they use. You would need to convince them to add an option to update the internal AC state in |
Once again, a big thank you!! After you posted your reply, you got me thinking about where this could be implemented. So I went digging through Tasmota's documentation (it's not much, but it's been helpful in the past :) ). And lo and behold, that option actually exists:
Even though I cannot test this right now, I do believe this is the solution to my problem. And if I can get the authors of I trully appreciate your responses. This was not really an issue with IRRemoteESP8266, and as a result I had already closed the issue. Yet you answered with plenty of details (and even working code samples!), and that put me on the right track towards a solution. A level of support I have rarely seen even with commercial software :) Thank you once again! |
Version/revision of the library used
The one included in Tasmota 12.5.0
Describe the bug
"Clean" is set as a toggle as per issue #1676 , but this does not handle the fact that "clean" is automatically set to "off" by the AC unit once a cleaning cycle is completed.
To Reproduce
For a while now, I have had to work around "clean" being a toggle by using a higher-level component (I am using Tasmota_IRHVAC to control my AC unit, and they implemented a "toggle_list" in their code in order to fix this issue - see here for the details).
As you can imagine, I was originally glad to see that
clean
is now a toggle at the IR library level. However, this causes a different problem...On my AC unit, the "clean" setting is automatically turned off once a cleaning cycle is completed. As a result, the unit state becomes different than the one stored in Tasmota (and IRRemoteESP8266), making it difficult to activate a clean cycle on subsequent power ons.
Example (starting from a unit with
clean: off
, IRRemoteESP8266 also has an internal state ofclean:off
):I could probably fix this by toggling the setting (for example, sending "clean = !prev_clean" in step 6). This would fix the issue, but it would lead to continuous inconsistency between the unit state and the state stored in IRRemoteESP8266.
A better solution would be a way to change the internal state without causing an IR signal to be sent. I do not know whether this should be done at the library (IRRemoteESP8266) level, or in the higher-level component (tasmota_irhvac). That is why I am asking in both places.
The corresponding issue for tasmota_irhvac is here.
Thank you!
Expected behaviour
Need a way to keep the IRRemoteESP8266 state in sync with the unit state, even when the unit internally toggles the setting.
Output of raw data from [IRrecvDumpV2.ino]
Not really relevant - the problem is in the logic, not in the IR signal.
What brand/model IR demodulator are you using?
N/A
Circuit diagram and hardware used (if applicable)
N/A
I have followed the steps in the [Troubleshooting Guide]
Has this library/code previously worked as expected for you?
Yes, up to the changes in #1676 . But again, I am not saying those changes are bad - they actually make sense, and I was happy to see them! It is just that they introduce an additional issue, and I am not sure what the best way to fix it would be.
Other useful information
This library has been absolutely invaluable for me so far. Just had to say this somewhere, and I found no better place for it :)
The text was updated successfully, but these errors were encountered: