I am unsure if it's the individual device or just saving preferences that forces the events to start reporting again. There were no events being reported for devices until I saved the preferences on one of the devices. Afterwards it started reporting events. I'll do some more testing and see if I can reproduce the exact steps that cause it to happen.
Latest versions of both:
Unifi OS: 3.2.7
Protect Version: 2.10.11
I have had them both running on my hub for over a year and hadn't observed this behavior previously. No issues with hub load either before this week, but I wasn't really using a lot of the functionality of the drivers yet.
What I have observed over the past week is that your driver will stop creating events for some time and then will restart creating them (see the screen captures below from tomw's driver vs yours). This is happening on the camera and doorbell device types.
When I look at the parent device I do not see any issues/failures. NOTE: The screen capture was not taken during the 12:19 am to 9:28 am window. I will try to capture a screen capture of the parent device during a time when it is failing to create events.
Not sure how/why that would happen. There is nothing I specifically schedule during that time and I use almost identical websocket code as @tomw's (mine was copied from his with permission) and has only added some extra devices and responses discovered since. My EVENT code is different but the main thing there is that it checks to see if something changed before posting the event (or not) OR it is a forced event (always posts it regardless if it is a changed value, but these are not set to be forced).
I assume there are no errors in the logs with a login failure or some such for mine?
Not sure how you are getting so unlucky with mine. First the mysterious high load that went away, now a gap in events...
2024 is already starting out with too much coding, although I have mostly been working on my PixelController and device-side firmware...
I was just checking on the device again and I noticed that events were not being created after 3:18pm today. Below are the current attributes for the Unifi Protect parent (WebSocket Open = closed) now. During this time window, tomw's driver has been creating events.
More of an FYI. I just installed a new doorbell. The auto-setup for the doorbell chose the camera driver rather than doorbell driver. Which resulted in no push events and errors. The state value for Type is 'UVC G4 Doorbell Pro PoE'
That type is not one I have identified so I am not surprised it did not select the correct one. I will add it in and have an update posted shortly. After updating could you delete the child device and then run the "Get Protect Info" command to make sure it gets generated correctly as a doorbell?
Added recognition for the UVC G4 Doorbell Pro PoE (thanks @bill.d for posting the info) which will hopefully work off the bat
Added handling for additional data returned by the API (this was already done on my internal version and was going to be posted as 0.2.31 but the above change happened before I published it)
I'm having the same issue as posted above with the push event not being recognized in logs or events. If I push the 'Push' button on the child device page all I get is:
Ok. So my bet for the "push" event is that they changed it and it is reported differently (since it is a different device) and the code does not recognize it as a result. Can you send me a message with Trace logging enabled on the parent device when you push the physical doorbell? There will hopefully be logging that starts with "WebSocket Data =" that will contain it.
I cannot imagine the refresh method needs to be different since (and thus a different doorbell child driver) but let me know if that is a consistent error every time or such.
Added handling for the "ring" type when returned in WebSockets so that doorbell activity should be recognized properly.
Added the "ReleaseableButton" capability to the Doorbell child driver because it appears that the WebSocket MAY provide a "closeout" notice of the action (like it does for motion and other sensors) so this device should actually say when the button is released (unlike most button-related devices I have ever dealt with that only provide the push notice).
Altered the driver-specific attributes "Driver Name", "Driver Status", and "Driver Version" to remove the space in their name going forward.
FYI - new EA firmware (4.70.8)/app (3.0.10) for Protect. The doorbell has stopped logging the 'push' and I get an error in the parent. Note that it appears the tomw integration is still logging the push.
That error would have nothing to do with a regular ring of the doorbell as that command is only triggered if the child device itself is refreshed (which has no automatic scheduling for).
Did you select the refresh to try to get the push to update? Nothing changed on my end for how a push should be triggered and the odd part is that the overall code there is very similar to tomw's.
Are any other features "broken"? I tried doing a device-specific refresh of my floodlight and camera but they both came back with their expected response (no error). But then again I am still on the Official Release. If they changed how device-specific info is handled I could update for that but what I do not get is why your websocket stopped working.
Sorry, I probably wasn't clear. I pushed the 'Refresh' in the doorbell child after the physical doorbell did not trigger an event in Hubitat. That refresh generated the error and did not fix the performance of driver.
I put the driver in debug. Here's the 'Get Protect Info' from the parent:
There is 'stuff' being logged from the doorbell including button presses. It looks like we're essentially back to the 'pushed' event not being generated.
Inclusion of a system PowerDown command within the parent device
Handling for additional data returned by the API
Driver-specific variables and events with spaces ("Driver ...") will be removed the next time a Save Preferences is performed (if they have not already been removed) on both the parent and Doorbell child driver. Other drivers will get this as they are updated as well just to clean these out.
Even FURTHER simplification of the Doorbell pushed event... It does not even go to my ProcessEvent function anymore. The very first line in the "push" function will use the basic sendEvent command for it now. If this does not solve the odd behavior...
Something is just not working correctly. The doorbell is not registering pushes still. And the doorbell stops logging any events. A Refresh on the parent re-starts the event logging. Here are errors from debug. Note the camera with errors is a G5 bullet, not the doorbell.
These are not errors. This is just logging of stuff I do not have code for, basically stuff nobody has sent me a sample of before. Plus, as you mentioned, they are unrelated to the doorbell.
For the doorbell child, there should be Info logging that shows stuff like "Button 1 pressed & number of presses..." Is that showing up at least? Out of curiosity sake, what type of Doorbell is it?
I am publishing a new version to handle those new WebSocket types at least...
