Let's talk about Gladys V4

Development
580

If I can, no problem :wink: I also code in my spare time

The circle also bothers me, it’s not very visible and when we are at 5% the red bar will look like a dot. I prefer the progress-bar

582

A question unrelated to the display.
Regarding the camera service.
For now, there is an RTSP camera that is only used for one type of camera.
My questions are:

  • Do we need to create a service for each manufacturer and camera used by users?
    – Netatmo: indoor camera, outdoor camera,

    – Somfy:
    – Xiaomi: 

  • Can it be the same service and by selecting the type of camera in a dropdown menu?
  • Or does this service work for all cameras?
583

RTSP is not a brand or type of camera, but a communication/data transfer protocol. So to answer your question, you won’t need to create a service for each type of camera, but one service per communication type (I only know HTTP and RTSP for cameras).

I don’t know if @pierre-gilles has planned to create two services, but in terms of display, it will be in the same box on your dashboard, and for configuration, I think you will have a select list to choose the protocol, or it will be automatically detected based on the type of URL you enter on the configuration page.

rtsp://<IP_CAMERA>:port/something
http://<IP_CAMERA>:port/something

584

Hello,

both are already working :wink:
I access my cameras via RTSP and also via the Synology API which provides an http url.

For camera management (on/off/PTZ), we can imagine doing it via ONVIF, it’s a protocol compatible with 90% of IP cameras! There is a node library for that, so potentially we can create a service.

585

For RTSP, yes I know it’s a protocol.
To be honest, I have a Netatmo indoor camera.
I know there is documentation, but I don’t know how to integrate it into Gladys.
https://dev.netatmo.com/resources/technical/reference/security/live

586

You lost me after « onvif Â»

587

For the Netnamo cameras, I think you need to retrieve an authentication token from their API, try following this tutorial Tutorial for Domoticz.

588

The Netatmo is not compatible with « ONVIF Â», what a pity :joy:

589

Nothing to add :rofl:

590

However, I’m responding to his comment! I’m not sure if I should have a service per protocol. I find that it’s weird for the user


The issue I have with this method is that it’s very « tech Â». Why not have a service that groups all cameras together?

It’s simpler and that way it’s up to the developer to manage each protocol. Right?

591

Same opinion. A multi-protocol « camera Â» service that will cover maximum compatibility.

For other devices, other viewpoints could be started. I’m thinking about Bluetooth, which remains very generic, but « super Â» Bluetooth services that will use the initial Bluetooth service, by device type, I think.

But we still have a bit of a way to go before we get there.

592

How is this relevant? How can I define a switch type device (electric outlet) on Gladys 4. Thanks :slight_smile:

593

It’s true that it would be more relevant, especially for the average user like me.

594

Honestly, whether you’re an average user or not, everyone prefers to make life easier :slight_smile:

595

This is coming in the PR we did with @link39 yesterday!

https://github.com/GladysAssistant/Gladys/pull/512/files#diff-bcf142d83df7e91d31d916829f288698

596

Have you found what you’re looking for? I haven’t tried yet, but it shouldn’t be long. Off the top of my head, I’d say you need to add the appropriate parameters in DEVICE_FEATURE_CATEGORIES and DEVICE_FEATURE_TYPES in server/utils/constants.js.
Maybe consider the « energy-consumption Â» feature, even if it doesn’t exist on the plug you’re integrating, and consequently, add W/h in the units.

597

Oh but that’s wonderful! Great anyway, I’ve fixed the issue with the browser crashing on the Xiaomi service. Hopefully.

598

@pierre-gilles came to the rescue :smiley:

599

To address the debate on device grouping. I am 100% in favor of this kind of optimization to lighten the UI, make it more linear and less « DB dump in the UI Â».

I think we should nevertheless think carefully about the usage:

  • what are we trying to display?
  • for whom?
  • why?

For example, I don’t find the battery necessarily useful. The battery is useful to have an automatic notification when the battery is low, but the rest of the time, well, the interest is limited, why bother monitoring manually when a machine can do it ^^ that’s the goal of automation!

In the case of the camera service, all cameras work the same in the end, so I think we can rename the service to « camera Â» service simply. The camera service already manages RTSP + HTTP. Xiami, Somfy, and Netatmo are probably already compatible :slight_smile:

600

That’s great. Could there be a list of supported cameras in the future? Ones that have been tested by users.

This could allow the user to choose one camera or another, and be sure it works with Gladys.