Wondering if possible to add support for Inkbird ITC-306A about tuya-local HOT 28 CLOSED

If you can get dps information from it using tuya-cli, or any other method, I can take a look. It looks quite simple, a current_temperature, temperature setting and one or maybe two independant on/off switches.

from tuya-local.

Sorry what does dps stand for?

from tuya-local.

dps is what Tuya calls their device attributes. They are numbered, and some will also accept changes to the values.

If you run tuya-api get --id DEVICEID --key LOCALKEY -a (where DEVICEID and LOCALKEY are the id and key for your device), it will output them like:

{ devId: 'DEVICEID',
  dps: { '1': true, '2': 0, '4': 119, '5': 60, '6': 2383 } }

If you change the target temperature, you should be able to tell the current and target temperature apart, and there will be one or more true/false value for the switches.

from tuya-local.

Ok I tried tuya-cli
tuya-cli get --ip 10.x.x.x --id xxxxxxxxxxxxxxx --key xxxxxxxxx --full
and get this
\ufffdV\ufffd\ufffd[\ufffd\ufffd$3\ufffd\ufffdo\ufffd`uS:\ufffd\ufffd$\ufffdq(\ufffdU\ufffd'Qm\ufffd
which shows up as garbage in bash. Not sure what I am doing wrong?

Well not sure what is wrong no matter what values I but in ID and Local key I get those same results. Pulled these off of an xml file from a rooted android device.

from tuya-local.

Add --protocol-verion 3.3 to that command.
If you get a similar garbage output with the protocol version specified (it is definitely 3.3 though, as 3.1 devices output in plaintext and only require the key to set the dps), it could also be a wrong key. My device ID is hex, and my key is alphanumeric, so you may have them around the wrong way.

from tuya-local.

OK didn't realize the key changed each time it paired.
low is 25.7 high is 26 and on

 dps: {
    '12': 0,
    '101': 'C',
    '102': 0,
    '103': 'on',
    '104': 257,
    '106': 257,
    '108': 6,
    '109': 1000,
    '110': 0,
    '111': false,
    '112': false,
    '113': false,
    '114': 260,
    '115': true,
    '116': 783,
    '117': false,
    '118': false,
    '119': false,
    '120': false
  }
}

low set to 25.2

`dps: {
    '12': 0,
    '101': 'C',
    '102': 0,
    '103': 'on',
    '104': 257,
    '106': 252,
    '108': 6,
    '109': 1000,
    '110': 0,
    '111': false,
    '112': false,
    '113': false,
    '114': 260,
    '115': true,
    '116': 783,
    '117': false,
    '118': false,
    '119': false,
    '120': false
  }
}
'

High set 26.5

`dps: {
    '12': 0,
    '101': 'C',
    '102': 0,
    '103': 'on',
    '104': 257,
    '106': 252,
    '108': 6,
    '109': 1000,
    '110': 0,
    '111': false,
    '112': false,
    '113': false,
    '114': 265,
    '115': true,
    '116': 783,
    '117': false,
    '118': false,
    '119': false,
    '120': false
  }
`

And not heating

`dps: {
    '12': 0,
    '101': 'C',
    '102': 0,
    '103': 'on',
    '104': 257,
    '106': 252,
    '108': 6,
    '109': 1000,
    '110': 0,
    '111': false,
    '112': false,
    '113': false,
    '114': 257,
    '115': false,
    '116': 783,
    '117': false,
    '118': false,
    '119': false,
    '120': false
  }
`

from tuya-local.

It looks like a lot of unknowns in there. I can guess the second one is units (C or F), but not many others besides the 3 temperature ones you have highlighted above. Any idea what the 783 would be, or the 6, the 1000, the 'on' - is it an option for what the switch does in the desired temperature range, or is it the main switch? I guess 109 and 110 (or 102 or 12) could be identifying the max and min temperature range, but I've made that observation about heaters before and been wrong (that time it had 18 and 40 but the user claimed the minimum was 18, but maximum went beyond 40 - to confuse matters even more, I found a manual online that stated the range was 18-35).

When you say "when not heating", did you force it off with the main switch, or is that (dps 115) just indicating when it decides not to switch off because of the temperature range?

I think this can be modelled as a climate device with upper and lower temperature range at least, but the main switch would be useful to know. And whether both outlets are controlled by the same switch or there are seperate controls (a lot of false values in there for some sort of boolean sensor or switch)

from tuya-local.

Did you create an account on iot.tuya.com to get your key, or sniff the app traffic with a proxy?

I think sniffing the app traffic (which isn't possible with a lot of the latest apps) you can capture the schema from the device. On the iot.tuya.com developer portal under Cloud / API Explorer there are also some options to test out the APIs, one of which under Device Control is "Get device specification attributes". For many devices it doesn't return the full list, I guess only what the web API exposes and what the cloud tuya plugin to Home Assistant has access to, but it might help with identifying some of the others.

from tuya-local.

Ok on just means it’s on you can turn it off or pause it, it is always on if it’s working. Pausing means it never turns on the heater and off turns it off. Ok I don’t know the difference they seem to behave the same.
115 seems to be state of heater true it’s on false it’s off.
104 is the current temperature in C
106 seems to be min temperature
114 is high temperature setting.
109 is the high temperature alarm was set to 100 C
110 is low temperature alarm and
108 is time in hours to set set off alarm if it heats for longer then that.
111 is the high temperature alarm
112 is low temperature alarm
102 is temperature calibration offset
116 is the temperature in Fahrenheit
All temperatures have one decimal place.
I can find out alarm for continuous running well take awhile.

115 I just changed the temperature so it was within range.

No I just pulled the info off of android xml file.

from tuya-local.

OK, that's great, it has vastly reduced the number of unknowns. Anything that is not supported by the Home Assistant climate integration will only be available as read-only attributes on the entity, so if you want to tweak any of the alarm thresholds, you'll have to do it in the tuya app still (it might help if you can find an app that works with the developer account so you don't have to re-pair every time), but you'll be able to monitor the alarm statuses with HA automations and trigger notifications or whatever based on them.

The temperature high/low range is new for my integration, everything until now has just had one set point, but it is supported by the climate entity so should be simple to add. I hope to complete the integration over this weekend.

from tuya-local.

I'm pretty sure the alarm for continuous running will be 113, as it is grouped with the other alarms, and there is only that and 12 left unidentified (12 is possibly an error code)

Edit: I take that back, I had not yet added 117-120 into the config, and was looking only at the ones that I had in there.

from tuya-local.

Some preliminary support is in 0.6.3. Please leave feedback on how it works.

from tuya-local.

Huh HACS still only shows 0.6.2 as the latest version. Uninstalled and reinstalled same thing. Rebooted still shows 0.6.2 as the latest version. Had a look at installing manually but not familiar with it since the files/folders in the zip didn’t match the ones in the HACS installed folder.

from tuya-local.

Sorry, I just checked and github still had that Release in draft status. I released it properly now.

But HACS only checks for new updates I think every 10 hours, so to see the new release, you may need to select Update Information from the menu in top right of the Tuya Local integration card in HACS to make it manually check.

You can also select Reinstall from that menu and if "Show beta versions" is enabled, you can select main to install the head of main branch from git - though I don't recommend it in general, as I sometimes push work in progress to test it on my live system, so it can be unstable between releases.

from tuya-local.

Well this is strange. It seems like there is something wrong with GitHub's Release system. It is showing up as released when I release it, and shows as latest release on the main page, but when I check back a couple of minutes later, it is back in Draft again and 0.6.2 is the latest release again.

from tuya-local.

The release is done properly now. It was entirely my fault, a typo in the tag name, but I still don't like the way GitHub handled it by silently sending the release back to draft without raising any notification about the problem.

from tuya-local.

Ok installed. Is there any ports or anything that should be open? When I try to connect using same values as tuya-cli it says can't connect with this information. But those values return the dps in tuya-cli? My HA is running docker and no ports are forwarded. The container can ping the device.

I haven't had any issue with other integrations working but not sure if this is a push or pull integration

from tuya-local.

There are currently no incoming ports that need to be opened, it is a polling integration. You may need to close the app on your phone for the device to allow HA to connect.

from tuya-local.

Force closed apps didn’t fix anything. I get Unable to connect to your device with those details. It could be an intermittent issue, or they may be incorrect. The values are the same that I use in tuya-cli. I can try to connect and nothing in HA and I get this message. If I connect with tuya-ci with those exact same values it works. Anything with protocol?

from tuya-local.

OK, I found an issue with some left over old code making assumptions about which dps are returned by devices. If the device doesn't return dps 1 or 3, it decides it hasn't communicated successfully. Will fix this tonight.

from tuya-local.

I've released a fix in 0.7.1

from tuya-local.

Ok it works. Can set the low temperature. The heigh temperature just goes blank when trying to change it. Then goes to the low value when the down arrow is pushed but doesn’t actually seem to change it. The presets don’t seem to do anything. Thanks, better functionality then with the tuya integration.

from tuya-local.

I suspect the high temperature going blank is because HA is sending both Low and High temperatures together every time one of them changes, and the code first sets the low temperature then the high temperature in that case, but the device may not be ready for a second command yet when the high temperature comes.

I have modified it in 0.7.2 to send both at once. Hopefully that will work a little better.

For the presets, can you confirm the values other then "on"? I set "pause" and "off" based on your description, but maybe the values in the dps are different than in the app UI.

from tuya-local.

from tuya-local.

0.11.0 contains some improvements to the low/high temperature and value scaling, which may improve the previously reported problem with the high temperature setting.

from tuya-local.

It's improved a lot and looks good but for whatever reason it still doesn't set the values. It looks like ti does but the next polling of the device everything goes back to the previous values.

from tuya-local.

I purchased one of these myself, but I don't seem to have any issue with setting the temperatures. One thing I did notice is that it came set to F, and when I changed it to C without changing anything else it went a bit crazy. But after setting the limits to sensible values for C as well as F (the main one was the lower limit of 32), it was OK.

It does become difficult to adjust if the lower and upper temperatures are set to the same temperature, or 0.1 degree apart, but that is just a UI issue because you can't tell which handle you've grabbed and if you try to drag it beyond the other one, it won't go.

Interestingly, the tuya developer portal reports that the device is not supported, which I assume means it won't work through the cloud API at all.

from tuya-local.

OK, playing around I have found one problem. When the temperature unit is set to F, the current_temperature is still being returned as C, but HA is interpretting it as F.

from tuya-local.