Wifi sensor no endpoint

[Wheemer]

Anything that can be done to support these sensors?

tuya-ab2e3ba4f7c529f8ccdadb61bb7f3139-T & H Sensor-9d4693de98528b17731fc4eafed29ee6.json

[xZetsubou]

You shared something that is un-related to this integration or the device it self, if you have set-up localtuya then download the entry diagnostics, however I'm really not sure what is the issue with your device have you tried to add it to localtuya? I can't see any bug here, keep in mind this isn't like official integration you add the device your self it won't added automatically when you add the integration follow the documentation.
https://xzetsubou.github.io/hass-localtuya/configure_add_device/

[Wheemer]

I uploaded what the official tuya addon showed because I cannot get it to add in local tuya. I thought the entire point of you version was that it did auto find everything?

[xZetsubou]

It has auto configure feature that configure the devices entities for you if it supported, but it doesn't auto add the devices.

edit when you click on configure and add new device there is also a checkbox and if you turn it on it will try to add the devices that is recognized from your cloud and support the auto-configure feature.

[Wheemer]

Yes I did that and it says no endpoint found.

[xZetsubou]

post a picture of the error or logs. does you devices shows in the discovered devices field like the zigbee switch in the image on my last comment?.

[Wheemer]

I am trying to get someone on site to hit the button so I can get you the logs, proving difficult.

It shows up perfectly there as I click the check box and the next screen all seems ok. When I previous got them to hit the button it did communicate however that's when it said no endpoints. If I did not time it correctly then I just get a normal can't reach error.

When I have the logs I will post back, maybe this evening.

[phrak]

Try manually adding a 1 into Manual DP field at the first screen, and see if it let's you add a basic device.
From there, you should be able to dump the diagnostic log.

[Wheemer]

Nice that worked... it stays alive for like 5 seconds so very hard to get timed.

localtuya-a3a089e2620a36641f4ff3ce4f36e366-Spike Climate-7f76f73d458e2f6403b22f19bc0c9218.json

[Wheemer]

It normally says unavailable for all sensors after specifying the dp 1. However it is updating, I saw it report proper temp and humidity for a sec and then back to unavailable. Battery looks to be expecting a percentage but I think it only reports high low.

[xZetsubou]

Adding the device using the manual DP won't help you much if the device it self doesn't reports the values it self, and this can be caused by many reason for common example. Then show an error that it connected but no DPS found.

1. The device is being used by different client e.g. Smart Life or Tuya apps OR another local integration you need to disconnect any connection to that device when you add it. because this may lead to inconsistent connection
2. The protocol version is wrong.

I don't know how did you added the device did it got discovered by the integration it self when you choose add new device option OR did you insert the data manually.

Assuming that you ensured that everything is fine and the issue still happens then you will need to enable the debug for both the integration from configuration.yaml and the device is self.

So the first thing we should know is why the device it self doesn't reports it values adding manual DP won't resolve this.

[Wheemer]

This was what it detected automatically. I did not input anything but the 1.

I do have the default tuya integration running that is also connected to the sensor. I will disconnect that and attempt to readd. I will report back when I manage to accomplish this.

Thanks for your help, have a great day!

[Wheemer]

OK I disabled regular tuya and tried to add the sensor again. It will not work without adding the manual dp of 1. Then it adds and seems to show values for a moment, then it goes back to unavailable. The battery said high% for a moment as well.

Here is the latest diag file
localtuya-a3a089e2620a36641f4ff3ce4f36e366-Spike Climate-7f76f73d458e2f6403b22f19bc0c9218 (1).json

EDIT: oops hit close by mistake, sorry.

[Wheemer]

temp is reported as 3.44 instead of 34.4 and humidity is .28% instead of 28%

I see it come alive when the sensor wakes up, but then it goes right back to unavailable. Is there any way to make it not do that?

[xZetsubou]

Fixing the numbers scaling factor is doable Manually: Go to integration page then
click on configure -> reconfigure the device -> select the device then process with submit until you see the sensors configuration.
Change the scaling factor from 0.01 to 0.1 for Both Humidity and Temperature.

I'll fix this if possible in auto configure entities next releases.

I see it come alive when the sensor wakes up, but then it goes right back to unavailable. Is there any way to make it not do that?

If the sensor goes into sleep so fast then there is nothing I can do here this is device behavior which I can't do much. Your device behave similar to this issue: #110

And yet I'm not sure how to fix this since I haven't had any device behave like this.

[Wheemer]

It is the same problem. I also have a door sensor that does the same. The battery powered tuya devices all behave in this manner from what I have come across. I would guess there is some caching going on at tuya's end.

If it's not possible for local tuya to cache the output then I suppose battery sensors are just incompatible with local tuya.

If the device continually shows as offline when it's in sleep mode then I guess my only option is the native tuya integration, which is disappointing and will make me replace it with some esphome device I suppose.

[xZetsubou]

Not really, not all battery sensors behave like this. For example, my snzb-03 doesn't do that. The same goes with many sensors I saw with users here.

However, I haven't tested refresh scan with this kinda of devices because in code it says refresh dps are only for 3.3, so if the update dps works for 3.4 as well it may fix the issue. Try to add a refresh scan, and you need to add the dps into rest and update dps fields

Again, because I don't have any device behave like this, it would be difficult for me to debug if there is a way to keep the device a wake.

edit the output is cached however the difference between localtuya and HA Tuya is available logic if the device goes into sleep localtuya will consider the device is dc'd because the device probably disconnected from network, but HA Tuya will still consider the device is ON. The only thing I can think of is that is by sending a payload to the device every x seconds to stop him from sleep.

edit2 I just placed an order for humidity sensor and it should arrive tomorrow, If the device behave similar to yours, it would much easier to debug it.

[Wheemer]

I do not think we can wake the device, it wakes on it's own when it detects a change in temp.

This is the one I have: https://www.amazon.ca/PHOVOLT-Hygrometer-Thermometer-Temperature-Notification/dp/B0B99FJJDW/ref=sr_1_1?crid=1FAQT7PSZWR1O&dib=eyJ2IjoiMSJ9.nP88shPkSxA-bs10buBqFrwVndpYYcx1aXRB9iQvqNQc5ESZFuTBXRrCLgQcLpzNvqL7rHKoJHdoB0TysxmTxIpr6NjAdnEEABeUxf68eSFX1_woais-1kQIm3ec1d0iBYkA0XHDjmCZmO0djJLgUIgMGfzJvOQmOxEx5Wx_sPbHSkh3wy8sknnRTKbJbOEXRdODmTOr7BzfpQodpZWqzATsuXLk0V9mgSMKXrp1kY3yjfyMsyhVLblE7ebN1HXAShyQjmfmdnU6QeZwkq7l80GwmqHmNOWRaNB8pzdM9P8.mSAZK3vtxeYxz1s75MS3COJ-9Grl_qjV3fILuJ7L_0A&dib_tag=se&keywords=tuya%2Bwifi%2Btemp&qid=1708270079&sprefix=tuya%2Bwifi%2Btemp%2Caps%2C115&sr=8-1&th=1

[xZetsubou]

update: since last week, I bought T&H sensor similar to the one you have and it also goes into sleep, I made a fix for this kinda of devices and it works fine for me till now, however to ensure that it's stable I may still need to test it more, do you want to test it as well?

[phrak]

Downloading now for testing.

I wasn't having any major issues with my wsdcg sensor, but every few hours it would return a zero reading on the Temp & Humidity values, so graphs and averages would thrown way out.
I also could never use it for any Automation triggers, because it would false-alarm all the time.

Testing master b83c193 now

[xZetsubou]

@phrak
I haven't pushed it on master yet however if I did I'll update here. currently there is a little thing needs to be handled better.

[phrak]

oh ok, no problem. I thought that 138792a was the change.
All good, let me know if you want me to test anything in particular.

[Wheemer]

Yes ready for testing as well.

[Wheemer]

I have a tuya wifi door sensor that does the sleep thing too, will this work around perhaps work for other sensor types too?

[xZetsubou]

Hello, I updated the master version and it should add the workaround I made for low-power devices however you will still need to insert the device sleep time your self. re-configure the device or when you add new device insert the time that if it exceed and the device didn't comeback it will be consider disconnected. from the Image I specified almost 12 minutes if the devices didn't report it will considered as offline.

I recommend you to put more then if the device usually wake up every 10 minutes set at 20 - 40 minutes sleep time.

[Wheemer]

It seems the UI will not allow me to update to master, upon selection it reverts to 3.2.4.2

I downloaded it manually and replaced the localtuya folder and restarted. I am not on site so I was hoping to see those option in a reconfigure device, but don't.

[RichardtGit]

With devices that goes into sleep mode, instead of showing unavailable can't it be coded to remember the last state it was in like open or closed and with battery percentage the last battery percentage before it went into sleep mode instead of showing unavailable.

[xZetsubou]

@Wheemer I don't understand HACS bug that some people don't see "master" versions.

@RichardtGit This is the idea behind this changes!, It does restore the states however if the device exceed the time you set without reporting any states it will becomes unavailable it it will overwrite the stored states.

[xZetsubou]

It seems the UI will not allow me to update to master, upon selection it reverts to 3.2.4.2
I downloaded it manually and replaced the localtuya folder and restarted. I am not on site so I was hoping to see those option in a reconfigure device, but don't.

I think that you haven't update to master correctly, or you missed the option it's on the main configuration before entities config.
you still can't see it? I may just push a release with new changes.

[Wheemer]

When I select master in the drop down, it refreshes as still the current version. I have successfully updated your plugin to master before so this seems a new issue with home assistant. I am running the latest beta version.

I thought just downloading and overwriting the localtuya folder would be enough. Maybe I'm not getting the right download?

[xZetsubou]

It should be an enough if you downloaded the master and extract it then move it into custom_components

[Wheemer]

Yes I did that before but somehow must have grabbed the older zip. I did it again and I see the setting, I have it set to 300.

Thanks, we will see. I'm not sure but it still seems through tuya the sensor has way more updates than localtuya sees. Testing that now.

[Wheemer]

It seems to be staying alive now so thank you for that. I am getting unknown for battery dp 3, I'm expecting high, any way to fix that?

[xZetsubou]

but it still seems through tuya the sensor has way more updates

Both localtuya and smart life works the same if the devices wakes up it will be update in both cloud and localtuya.

am getting unknown for battery dp 3

Share the device diagnostics, after configuring it.

[Wheemer]

localtuya-a3a089e2620a36641f4ff3ce4f36e366-Spike Climate-7f76f73d458e2f6403b22f19bc0c9218 (2).json

[xZetsubou]

Re-add the device and configure it automatically I have made changes for sensors entity there was an issues with battery device class and unit showing "%",
Or delete only battery entity from config flow then re-add it manually.

edit: if possible let me know, if the device works without an errors for hours, so I can release the changes.

[Wheemer]

Will do, 47 mins so far of consistently working. I've removed tuya and now have this running a lizard's climate.

The battery still say unknown after just removing and readding it, since I am not on location to be able to re-pair.

localtuya-a3a089e2620a36641f4ff3ce4f36e366-Spike Climate-7f76f73d458e2f6403b22f19bc0c9218 (3).json

[Wheemer]

One hour of working perfectly, I'd say it's good to release.

[Wheemer]

I reconfigured the battery sensor as a binary sensor and it's now saying normal. I don't think this is right as it should say high.

[xZetsubou]

I reconfigured the battery sensor as a binary sensor and it's now saying normal. I don't think this is right as it should say high.

It reports what device sends 😄, so it should be fine maybe the device reports normal / high since it's in between?? mine behave the same sometimes it reports high and sometimes normal.

[Wheemer]

I see the word high when going through the setup of the entity.

It's also not currently even battery powered, it's got a 3v power supply wired to it, but it might go back to battery so still wanted to get it working well.

edit: in other words it always reports high.

[xZetsubou]

I see the word high when going through the setup of the entity

What do you mean by this ?

edit: the values and codes in entity setup are cached from the moment you connect to the device it has nothing to do with entity after that.

[Wheemer]

The value localtuya is being fed is high. However no way of configuring it seems to pull out that value.

[xZetsubou]

This values are cached from the moment you connected to the device it's, so if you delete and add the device again it will change into new values however these has nothing to do with the actual value. it just there to give the user an idea of what value the dp return and it only a hint that can be used in manual configure.

this is a battery sensor so it should be a sensor not binary sensor the actual and current value is what is reports in the sensors "battery level"

[Wheemer]

I just realized it was me selecting device class battery that caused the problem. Leaving the device class empty and now the sensor properly reads high.

Thanks a lot for your help!