New test version (0.0.24) that adds the motion alarm to the device tile.
This required changing the class from camera to sensor but I can’t see that it takes anything away but let me know if you see anything that goes missing (or should that be don’t see ).
(As it was a quick one I managed to slip it in while wait for work code to build so don’t tell my boss )
Hi Adrian, can you imagine the functionality of casting the homey data, eg temperature to the camera, so you can get some kind of dash information on it? Or is it just nnot possible anyway? Thanks
It looks like the Profile T specification allows setting the On-Screen-Display text so it might be possible. Once the current features are stable I will look into it further to see if I can find any details about it. The main problem is to get official detailed specifications requires being a paid up member. So unless I can find free information on the web it is very difficult to know what the format of the commands are.
I have setup a page on GitHub for translations. If anyone is willing to help out and translate the text then I will add then to future updates. I have include instructions in the document.
Version 0.0.24 is now live and there is a new test version 0.0.25.
The test version adds an option to switch back to Pull Events if both types are reported as supported.
Push events are more efficient for homey as it doesn’t have to keep polling the camera. However Push events may not work on some network setups. The switch is in Advanced Setting and called Prefer Pull Events. The switch will only have an effect if the camera reports support for both types of events.
Version 0.0.26 is now in test. This adds retires to the event image capture. I have found that my HikVision camera can only send the snapshot to one client at a time. Therefore if I have the notifications turned on in the HikVision app it gets first pickings on the image and causes Homey to timeout. So in this version it will try up to 3 times to grab the image. I also found that setting the delay in the Advanced Settings to 2 seconds prevents the race condition and actually means the image is captured quicker as the network timeout is about 10 to 15 seconds.
I presume this will not be specific to the HikVision camera so it is something to consider if you have other things capturing snapshot images.
First of all congratulations on this application. After testing the different versions I had better operation on the different camera brands in version 22. With the following some of them no longer work. And would it be possible to change the CLASS of devices to “CAMERA” type as before and not “SENSOR” as is the case in the latest versions?
If I change the class back to camera then we loose the notification icon on the device tile. Is it something specific that you think the change has caused?
What is not working now that was working?
Have you tried with the latest test version and setting the prefer Pull point event option.
I coded part of the homeydash interface to display the image of the cameras when we click on their icon.
There is a previous version where one of my cameras displayed notifications and the “Camera” Class on homeydash.
I tested the latest version which is indeed more stable on event detection. But some brands do not display the notification on homeydash but on the mobile application.
And another brand detects a bad PORT and therefore the camera is not accessible.
I will look into Homeydash as i do use that but just not thought of putting a camera on it. I tried lots of things but couldn’t find anything that stopped working when set to sensor. Maybe I can make it an option in the advance settings so users that want the notification icon can set it to sensor while others can set camera.
Could you send me a log of the one that has the bad port as I am not sure that is related to the class.
This is the one that I am a bit confused about.
It could just be that the ONVIF port shown in the Port field is different to the snapshot URL.
The ONVIF port is where ONVIF commands are sent. The snapshot URL is is where the image is fetched from which is not necessarily the ONVIF port as the image can be available to non-ONVIF clients as well. The URL is fetched from the camera using an ONVIF command which returns the full URL including the port.
If you can capture the startup information in the diagnostics log then I can verify if that is the case here.
thank you for the information I just looked at more information on the third camera and indeed it is a brand that makes a “false” onvif protocol I think it comes from the.
So I think you shouldn’t take it into account for your application.
Could you try the test version as I have made changes to that file. Even if it doesn’t fix the problem it will show me the correct line number where the error occurs.