search

arendst / Tasmota

Alternative firmware for ESP8266 and ESP32 based devices with easy configuration using webUI, OTA updates, automation using timers or rules, expandability and entirely local control over MQTT, HTTP, Serial or KNX. Full documentation at
https://tasmota.github.io/docs
GNU General Public License v3.0
22.19k stars 4.81k forks source link

Integer overflow for TuyaMCU timers (uint16 vs. int16) #18048

Closed aph3rson closed 1 year ago

aph3rson commented 1 year ago

PROBLEM DESCRIPTION

A clear and concise description of what the problem is.

For TuyaMCU devices, Tasmota offers support for tracking of timer sensors (Timer1 through Timer4). These are mentioned as handling type 2 (integer) DP Ids.

However, there appears to be a signedness issue somewhere in the handling of these timers. As an example, this DP is returning a value of 36000 (0x8ca0), which corresponds correctly to the sensor value as an uint16 (10 hours, in seconds). However, Tasmota appears to be processing it as an int16, and reports the value as -29536 (same bit order, just incorrectly handling the sign bit).

08:13:21.583 {"TuyaReceived":{"Data":"55AA030700081D02000400008CA060","Cmnd":7,"CmndData":"1D02000400008CA0","DpType2Id29":36000,"29":{"DpId":29,"DpIdType":2,"DpIdData":"00008CA0"}}}
08:13:21.585 TYA: fnId=82 is set for dpId=29
08:13:21.588 MQT: tele/tasmota_D76E47/SENSOR = {"TuyaSNS":{"Timer2":-29536}}
08:13:21.591 TYA: RX value 36000 from dpId 29

It's unclear if these timers are intended to be always-signed, or always-unsigned.

REQUESTED INFORMATION

Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!

TO REPRODUCE

Steps to reproduce the behavior:

  1. Locate a TuyaMCU device which utilizes an integer DP that is out-of-range of an int16.
  2. Configure said device to output that integer to a timer FnID, e.g. 21 (Timer1).
  3. Observe that the value is processed as if it were an int16, and exhibits integer overflow.

EXPECTED BEHAVIOUR

A clear and concise description of what you expected to happen.

Proper processing of the integer in question.

SCREENSHOTS

If applicable, add screenshots to help explain your problem.

Log outputs are above.

ADDITIONAL CONTEXT

Add any other context about the problem here.

I think this is the first time someone's put Tasmota on one of these - they're not popular devices, but they should be similar to most-other Tuya devices. Note that the Tuya electric blanket docs (device type dr) do not appear to be accurate for this device.

(Please, remember to close the issue when the problem has been addressed)

barbudor commented 1 year ago

What are tuya timer used for? Is there any use case where a negative time would make sense?

I'll try to have a look in Tuya docs to see if they say something

aph3rson commented 1 year ago

What are tuya timer used for?

In this device, it's to indicate how many seconds are left until the device shuts off (sleep mode timer).

Is there any use case where a negative time would make sense?

Not for this device/one that I'm aware of.

aph3rson commented 1 year ago

Also, FWIW, I ended up using a workaround here: the DPs for the timer are unbound, but still detected with a rule on a TuyaReceived event:

Rule1 
  ON TuyaReceived#DpType2Id28 DO Publish2 stat/%topic%/TIMER1 %value% ENDON 
  ON TuyaReceived#DpType2Id29 DO Publish2 stat/%topic%/TIMER2 %value% ENDON

While this isn't quite the same as having them both output to the sensor topic, I found this route slightly easier for my intended usecase anyways (seems similar to SetOption4).

barbudor commented 1 year ago

I've not been able to find a confirmation in Tuya doc but that seems reasonnable to have a timer unsigned Added as point 3) in PR https://github.com/arendst/Tasmota/pull/18085

Jason2866 commented 1 year ago

Fixed PR is merged.