I'm going to PM you to troubleshoot more.
1 Like
@albertjmulder ended up having some kind of networking issue between the cameras and NVR that needed to be sorted out. Getting the cobwebs out of a system upgrade is always the fun part. If it just worked, would you feel like you really got your money's worth out of the upgrade? 
1 Like
Quick question: does anyone use the displayImage attribute on their virtual devices?
I am likely going to change how images are stored by this driver, and it would make sense to remove displayImage at the same time if it isn't needed.
Anyone that is using my Image Server app to put images on dashboards would be unaffected.
Are you changing the image attribute?
I'm actively using that for the dashboard images in my parent UniFi Controller Manager app.
Yes, likely! I will look at your code and PM you to coordinate. Thanks for the ping.
My Image Server app is now in its own repository:
It is listed in HPM. Search for keyword "imageserver".
The app still provides the ability to use snapshots from take on dashboards. I also recently added the ability to send Pushover notifications when a new image is captured.
Please send any additional feature requests my way.
This app version will be a required update for future versions of my camera drivers*, so if you are a current user please update now and let me know if you have any issues or migration questions.
* why required?
Hubitat staff recommended that I move images stored by take into the file manager storage of the hub, which is now possible as of Hubitat platform version 2.3.4.132.
This version of the app supports reading files from the file manager, which is the only format that future versions of my drivers will support.
The imageServerApp is also backwards-compatible with previous driver versions which stored the image contents directly in virtual device attributes.
1 Like
All, a user reported a bug to me that made this version fail to properly display images from the existing drivers.
I fixed the bug, so anyone who already installed should either 'repair' in HPM or manually update the app code from GitHub. Sorry for any confusion!
1 Like
Continuing from here: Unifi protect camera error after update - #4 by jimmckinney
@jimmckinney, those webSocketStatus prints are expected behavior and are innocuous. You can disable debug logging on the UniFi Protect Controller (parent virtual device) if you want them to go away.
I'm stumped by the "excessive hub load" exception, especially if the hub is running smoothly otherwise. @gopher.ny, can you enlighten me on whether that is referring to a lot of events or a lot of processing time?
And assuming this is a new occurrence on @jimmckinney's system, is there anything in a recent update that might have changed what triggers this warning?
Cumulative processing time is > 33% of a single CPU core over hub uptime.
1 Like
Is that 33% of total uptime or total busy time?
Here's what I see on mine. 30% of busy but only 1.3% of total, which seems unremarkable.
Does this now integrate directly with UNVR and HE? I would like to not have to run a Raspberry Pi if I can help it. I just want to be able to get the doorbell press to play a tone on my Google Mini's. I have 2 x G4 Doorbell Pro's.
Yes, it runs natively to HE now. No Raspberry Pi required. Doorbell press events are a primary functionality and work great with my G4 Doorbell. Other users are using it successfully with the G4 Doorbell Pro.
It's looking at the total uptime, the second column. This tends to penalize devices that are startup heavy.
Ah, makes sense. @jimmckinney, what do you see in the "% of total" column in the Device Stats view (under Logs)? Does it trend down over time after a reboot, and do these errors eventually stop showing up?
@gopher.ny, do you have any examples on how to properly handle these hub-level exceptions so they don't look alarming in the logs? I don't think handling that exception in every method (or maybe it's only commands?) is very scalable, so I'd appreciate any pro-tips.
I notice the "% of Busy" is 97.7%. Just a side note, I have a lot of camera's... 18 of them. Don't know if that matters. Or maybe I need to reinstall the drivers because something got whacked out when I updated the hub.
Thanks for the help here!
Whoa! The 97% of busy is high, but the 34% of total is what is triggering that warning.
The 23,000 seconds of busy time looks suspect. What is the total hub uptime? That is like 6 hours of busy time, which makes me wonder whether something got stuck spinning somehow.
Have you restarted the hub, and are you able to reproduce these stats reliably? If so, let's chat by PM to get some advanced logging and try to optimize the operations.
Important note -- if you are using the take command for snapshots, this driver update requires Hubitat version 2.3.4.132 or later and my hubitat_imageServer app in order to display and use the images.
I just posted v1.4.0 to HPM and GitHub. This version moves the take image files to the File Manager in Hubitat.
This will reduce size and stress on the Hubitat database. Any previous users will notice that the snapshot no longer appears on the device page. Instead, a timestamp of the most recent snapshot will provide a visual indication that the snapshot was successful.
If you want to use the snapshot contents for dashboards, web viewing, or notifications, you will need to also install and use my Image Server app.
1 Like
I noticed with the new image server that the name of my cameras and the urls names are different One uses the Device Label, and the Other uses the Device Name. Can yo make them both use the Device Label?
Also is there a way to make the Device Settings Page load the Pic so we can see it working there at a glance without having to go to file manager and pull the file. And can we get it to save the file with an extension like jpg. and better file name, like adding the device label to the beginning of the name with _ to replace space:
Example:
639a4da803e60603e4003405-motion
becomes:
Driveway_Camera_639a4da803e60603e4003405-motion
This would make locating the correct image much easier.
These are all good suggestions.
I don't understand your comment about the device names and labels for the URL section. The URL itself has the device network ID (DNI), not the name or label. However, a "secret" feature is that you can actually use any of the DNI, name, or label and the URL will still work. Will you show me a screenshot of the device page and indicate which values you wish would appear where on the app page?
I can add .jpg to the files in device manager so that they're easier to view while you are browsing the file manager. I'll do that the next time I update the driver.
I do not want to change the file name itself, because right now it is the DNI which is guaranteed to be unique and which is not based on fields like name or label which are more likely to be edited by a user (which could lead to invalidated references to images and orphaned image files in the file manager). EDIT: I have an idea for how to possibly support what you suggested. Will give it a try and let you know.
