[BK7231N/CBU] Tuya TH01? Generic Wi-Fi Temperature & Humidity Sensor [CHT8310]

kuncy7 wrote:

I tried using cloudcutter, without success.

Is there a chance for a profile for this sensor?

kuncy7 wrote:

I've asked this before.
Is it now possible to generate a profile for this sensor based on the data we have?

divadiow wrote:

@p.kaczmarek2 interesting there are 3 devices with "CHT83x" in the keywords, but none with pin assignments.
also, can the template creation/import function add secondary channel support so ""CHT8305_SDA;0;1" is valid

divadiow wrote:

kuncy7 wrote:

I've asked this before.
Is it now possible to generate a profile for this sensor based on the data we have?

it seems you can generate your own cloudcutter profile using a firmware dump, so I guess it's possible. Cloudcutter is a different team, unrelated to Elektroda, I think.

Quote:

This device was already added as Tuya Generic TH08 Temperature and Humdity Sensor v1.0.0

However, this is an NL (battery) device, and these sometimes will not work correctly work with the cutting process. They will cut and get an A- prefix, but they may not activate and receive a schema or flash 3rd party firmware. NL uses a modified join, and is much more sensitive to network timing than other devices. You're welcome to attempt the existing profile, but serial flashing may still be necessary.

p.kaczmarek2 wrote:

Just choose an unused one so it does not interfere with anything

p.kaczmarek2 wrote:

Remember that you need to update OBK as well in order for setPinChannel to support secondary channel

p.kaczmarek2 wrote:

@hojnikb do you have a lab power supply or something, to replicate that scenario? I think I could help with that but we still would need to test the new mechanism well before releasing it.

divadiow wrote:

p.kaczmarek2 wrote:

Just choose an unused one so it does not interfere with anything

ah, my previous question is already answered. BAT_ADC and BAT_Relay should have channels set that are different to each other and to any other channel set on the same device.

Added after 14 [minutes]:

final template and PR https://github.com/OpenBekenIOT/webapp/pull/77

Code: JSON

Log in, to see the code

p.kaczmarek2 wrote:

@hojnikb do you have a lab power supply or something, to replicate that scenario? I think I could help with that but we still would need to test the new mechanism well before releasing it.

TheNitek wrote:

According to home assistant my sensor reported 255.9°C tonight (twice). Has anyone else seen this?

{% if states('your_temperature_sensor')|float > 200 %}
{{states('your_temperature_sensor')|float - 256}}
{% else %}
{{states('your_temperature_sensor')}}
{% endif %}

p.kaczmarek2 wrote:

The Home Assistant discovery must be done after configuring the Battery driver. If you have run the Discovery first, then you must run it again.

hojnikb wrote:

Yes, i have a lab bench supply, so i can replicate that pretty easily. But i'm fairly certain this happens all the time.

$batteryVoltage

p.kaczmarek2 wrote:

hojnikb wrote:

Yes, i have a lab bench supply, so i can replicate that pretty easily. But i'm fairly certain this happens all the time.

That's a very good news, so how do you suggest we handle the battery issue?

First of all you need to have a properly calibrated battery driver. Then we may try doing something, maybe, if battery driver detects, then force deep sleep for 1h? Or for 6h? The only problem is.... if user replaces the battery, it will still sleep. I am not sure. What do you think?

This could be done even with :

Code: text Expand Select all Copy to clipboard

$batteryVoltage

in script