Seems to work fine... Shows battery, shows dry to wet and back to dry...
1 Like
@kkossev - I haven't had a report from the first sensor I installed since April 7 when I first added it to my hub...so five days. Is that normail for these devices? When I first set it up it was pretty chatty - see events page info below from that day.
I removed the battery it shipped with and put in a fresh battery, that didn't seem to change anything, still no battery or status reporting. Do you know what the expected interval should be for reporting battery level and or general status? I have Descriptive Text Logging enabled.
I noticed similar w/the other sensor I had added to my mesh but not installed reported on the 7th, it also went radio silent w/no reporting until today when I woke it up by pressing wet thumb to contacts.
It's a low power device. The best way to check reporting in my opinion is simply expose it to water and see if it changes on the device page.
Thanks...I was assuming they would have a daily battery check in as w/my ST/Centralite leak sensors. I can monitor battery level via a few different apps, but liked getting the daily reporting from the device as it made me feel a little better about it being active. 
I would still do the test for giggles to make sure it hasn't dropped off the mesh...
1 Like
That's a reasonable point! I have another Tuya leak sensor (TS0207) that is powered by 2xAAA batteries and it sends the battery level once every 4 hours (using the same driver). But the Neo Coolcam sensor does not send anything when dry... Just checked, the driver battery reporting code has 'isStateChange=true', which means that the battery event will be registered even when the value does not change, i.e. remains 100%.
There is also a state variable 'rxCounter' which is increased every time anything is received from the device (even if it is an unknown command that is not processed and not shown in the logs).
I will monitor it if it changes in the next days. But usually, the reporting intervals (including battery levels) can not be configured for all Tuya devices that I have dealt with.
BTW, I have received my Neo Coolcam leak sensor yesterday, so now I will be able to monitor and experiment with the actual device in hands. So I will postpone the next update of the driver until I have more info on the device check-in / health status.
2 Likes
Wow...one of mine has been getting busy - 345 on the counter since five days ago. Hate to tell it now one is listening to it... 
I have now set up a sniffer while the device is paired to Tuya Zigbee hub, let's hope it will catch something overnight.
I don't have a clue why your txCounter and rxCounter values are so high... At the bottom of the device web page do you see any HE apps that are probably trying to poll the device periodically?
It may be a good idea if I add a custom command to clear these stats so that we know where we start from.
Is it the original model we worked on or the one that I posted today?
It's the original model, came with the battery installed.
1 Like
Good question - two apps looking at it, meant to only have one looking at it but forgot to remove Battery Monitor after I set up Device Activity Check.
As far as I understand those apps, I didn't think either would be hitting the leak sensor over and over again so as to drive up the rx so much.
My other has the same two apps + a the Notifications app, but it has a lower hit rate for some reason:
Actually, the driver does not expose any command that could force sending anything to the device (such as Poll or Refresh), so it shouldn't matter which apps are subscribed or just checking the device events.
The sniffer results (when paired to Tuya gateway) are:
- every hour the device asks for time synchronization (Tuya specific command) and the driver sends the current date and time. This increases both Rx and Tx counters by 1.
- every 4 hours the device asks for local time synchronization ( ZIgbee 3.0 command). This is should be handled on Hubitat Zigbee stack low level, so I expect that no counters are increased here.
- every 4 hours the device sends a kind of 'check-in' report (the application/firmware version plus two Tuya specific attributes) - this increases the rxCounter by 1.
So in a 24 hours period we should have as a minimum the rxCounter increased by 24+6 = 30 and the txCounter increased by 24.
What can I do for a start is to make these 'check-in' messages displayed in the device logs with Descriptive Text Logging enabled.
For a final solution however we come back to the problem with the missing HE standard capability and standard event that is used for determining the online or offline state of the device. I do not like using the 'Presence' event for that purpose...
1 Like
As a non programmer, I'll ask how come? Is it due to battery consumption?
It has nothing to do with the battery consumption, but with the fact that the PresenceSensor capability was intended to be used for detecting a human presence (gelolocation). None of the HE inbuilt drivers uses the 'presence' event for devices online/offline notifications.... So when the Presence attribute is used not as intended in custom drivers, then HE Apps/rules lists that must show only true presence sensors are also populated with all kind of different sensors and other devices that has nothing to do with the person's location. There are several threads on this topic.
4 Likes
Man, this thing has OCD...not sure why it wants to check time so often, since it doesn't report it (AFAIK) and doesn't really need exact time to detect a leak. Weird...
That sounds like a good idea. That will provide some sort of consistent "Hello world" that can be used to at least show that the device is alive and reporting/connecting.
2 Likes
Well you see it's not actually reporting to YOUR hub... just to a strange looking van across the street. 
More state actors trying to steal your bread recipe secrets.. 
5 Likes
@rlithgow1 I have updated the driver with the fingerprint that you provided for the new Neo sensor - please let me know if the driver is picked up this time while pairing.
2 Likes
