-
Notifications
You must be signed in to change notification settings - Fork 833
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
Argo WREM2 v1 commands not decoded correctly #2133
Comments
Disclaimer: I do not own a
|
uint32_t :6; |
... so I figured to try to just cut the message size
96->90
and it seems to have improved the situation.Take a look at #2136 for experimental ❗ changes that address it (maybe 😁 ).
@mateuszdrab - You may want to try to compile with the experimental changes from #2136 and see if it improves anything.
One thing I have noticed is the iFeel
(room temperatures) decoded by the lib seem to be +1°C
higher than what you report with the data. Could you double check (also in the iFeel reporting mode, when no button is pressed on the remote, but it periodically sends the room temp updates)?
Is the room temp reading you report coming from the remote itself, or a separate ambient sensor you're using?
Damn, you're a star 😀 The result speak for themselves
Regarding iFeel, the temp reported was initially 20 and that is what matched the screen on the remote. I can compile Tasmota with that version of the lib and test a bit more if you like? |
Just built Tasmota and I can confirm it works fine there as well, codes are being decoded correctly and Home Assistant is aware of the updates from the remote (I'm using the Tasmota-IRHVAC component) |
From captures in issue crankyoldgit#2133 (confirmed valid by the OP) Signed-off-by: Mateusz Bronk <[email protected]>
@mateuszdrab Glad it worked for you 🥳 , thank you for confirming!
|
I'm glad it appears to be working. I was a little worried as I never tested non-byte alligned sizes for the array based protocols. I'll try to find some time to review the code. (Sorry, I've been super busy with real-life stuff for the last couple of years) |
Note though that as far as I can tell, my changes do not affect the
|
Sure, I can capture some more commands from the remote and feed it back to you or put them in the E2E tests. As we speak about more captures, here are a few more (fan speeds this time). None of the options for The IRrecvDumpV2 dump shows fan speed is correctly decoded as auto, min, med, max.
Tasmota returns auto, min, med-high, and max with med-high being a problem as it does not match any possible choices for supported fan speeds in Tasmota-IRHVAC. I thought it was Tasmota's fault but the string comes from this library though. Do you think it's a mapping issue or should Another slight issue, sending |
Well, I added support for Can polish it up later and build on top of hristo-atanasov/Tasmota-IRHVAC#154 to make it show as Low, Medium, High nicely in the UI with proper icons and translations. |
Looking at the code... it's quite possible (and would likely be a separate issue if confirmed).
Separately: Aside fan speed and iFeel temp,do other commands you send to the device seem to work? |
I think that's the case Whether they work, I don't know for sure but it looks like the unit is working despite removing the remote out of the room and feeding it a temperature from another thermometer. P.S |
WREM2 and WREM3 iFeel IR commands are quite different (differ even in length), so I doubt they'll just work™️, but perhaps the vendor did include some forward-compat in their control unit...
I have the Ulisse 13 Wifi model (note there are also flavors w/o wifi) - see at the top of #1912 for photos of the unit and the remote.
|
Yeah I think you're right. It's not working the same way as it was with the remote in the room. Regarding fall back, I'm sure this is what happens, it does the same with iFeel off - runs compressor for a while and shuts off. That's probably because the temperature sensor is satisfied in the unit. I'll compile the solution from above to send a fake iFeel message and see if it returns to operating as expected. Unless I can recompile Tasmota with some quick fix/hardcode something to fix sending the WREM2 iFeel messages? Edit: Might be able to add that in here? |
Might be difficult. Tasmota uses IRArgoAC ac(_pin, _inverted, _modulation); //line 3091
if (send.command == stdAc::ac_command_t::kSensorTempReport) {
ac.sendSensorTemp(static_cast<uint8_t>(roundf(sensorTempC)));
} else {
argo(&ac, send.power, send.mode, degC, sensorTempC, send.fanspeed,
send.swingv, send.iFeel, send.turbo, send.sleep);
} Then again, even if it works, it probably deserves its own issue (enhancement request), as it is quite distinct from the decode errors you've been seeing initially. |
I did the below:
Added a switch case for this inAC under sendARGO
Seems to work, different message is sent; however, it is not decoded by my other receiver. Looks a bit too long.
Will use the sketch now to see if it's the same. Nevermind, it works and decodes now. |
Quick update I've ran the IRsend sketch with rawdata of the iFeel message for 24 hours and the AC has been running fine so I switched to Tasmota with my modified code to send the iFeel WREM2 reports and it's been working fine. I did make an adjustment to the transmitter circuit so perhaps that's why, I suspect the previous setup might not have been transmitting strong enough. Either way, once the fix is merged I'll PR my modification to allow sending WREM2 iFeel updates. |
Version/revision of the library used
v2.8.6
Describe the bug
I also seem to be experiencing decoding issues with a Technibel WREM2 v1 remote (similarly to #1859)
Symptom is that all IR communications received by Tasmota (and hence the library) are decoded as iFeel Temperature Reports instead of actual command messages. The provided reading for the sensor is erroneous (when misinterpreting command messages, otherwise the iFeel readings from respective reports are accurate and correct), suggesting that the message bytes are not an actual iFeel report but an actual command which is misinterpreted by the library.
Example code used
This issue can be reproduced on both Tasmota (tasmota-ir, version 14.2 and when using [IRrecvDumpV2.ino].(https://github.com/crankyoldgit/IRremoteESP8266/blob/master/examples/IRrecvDumpV2/IRrecvDumpV2.ino) pulled from master.
Expected behaviour
Commands decoded correctly and not as iFeel reports
Output of raw data from [IRrecvDumpV2.ino]
What brand/model IR demodulator are you using?
VS1838b, however the captures are consistent. Also tried another no brand IR receiver module and same issue persists.
Circuit diagram and hardware used (if applicable)
I tried this on 3 different builds, with 2 NodeMCUs and 1 pre-built (YTF) blaster with Tasmota on it.
The receiver hooks directly to D5, GND and 3V3.
I have followed the steps in the Troubleshooting Guide & read the FAQ
Yes
Has this library/code previously worked as expected for you?
No, tried versions down to 2.8.0
The text was updated successfully, but these errors were encountered: