Gladys 4 Beta is available! 🚀

News
100

Yes, I was thinking of adding compatibility at that level. I don’t know if I was clear.

101

It would be necessary to plan, especially at the code level, for example a JSON to list all the devices that work with this integration

102

Petit update to everyone on fixed bugs / new features:

  • Merge of Sonoff compatibility thanks to the work of @AlexTrovato :white_check_mark:
  • New Philips Hue compatibility thanks to @Helldog136 :white_check_mark:
  • Firefox Gladys Plus compatibility bug :white_check_mark:
  • Xiaomi device filtering :white_check_mark:
  • General Philips Hue UX improvement :white_check_mark:
  • The Docker image now uses Node.js 12 LTS :white_check_mark:
  • Empty integration page bug (addition of a fallback to EN) :white_check_mark:
  • Darksky link bug :white_check_mark:
  • Gladys Plus Backups page UI improvement :white_check_mark:
  • And many more :slight_smile:

It’s not as simple as that, each service UI is unique, so where would this list be displayed?

103

At the level of each service’s guidelines, it might be nice to add a « supported hardware Â» section, with a table indicating the support status (supported, in development, no support, etc.).
Additionally, this could allow those with less common hardware to speak up, provide the necessary hardware information to developers, and then test the associated developments, right?

104

Or else each service needs to add a page with the compatibilities and a direct link from the thumbnail if it exists

Edit: @Reno was faster :sweat_smile:

105

Grilled @VonOx :wink:

106

I had already mentioned this before because the competition is really ahead on this subject, and I think Gladys is lacking in this area.
See Eedomus
See Jeedom

Two ways to do it. I know that with Gladys we can do even better :wink:

107

For me, we can easily add a folder to Gladys containing several JSON files corresponding to the services, and the front end can have a dedicated page to list all available devices. It is therefore up to the developer to gradually add compatible devices.
This folder will simply be static.

108

So to summarize, there are 3 different requests in this thread:

  1. A list of compatible devices by service, directly within a service in Gladys
  2. A list of Gladys-compatible devices in Gladys, but at the « global Â» Gladys level.
  3. A list of Gladys-compatible devices in the Gladys documentation

All three are not opposed, we can certainly do several, but the source of the information must be the same. Otherwise, we know very well how it will end, after 1 update there will be a list that will not be up to date compared to the others.

I think it indeed makes sense to have this information entered in the Gladys repo in a configuration file since it is directly coupled with the Gladys code. This allows the developer to modify the configuration file in the same PR that will add a compatibility, and thus remain consistent in every way.

This information must be internationalized, so there will be a file per language.

We need to put tests to ensure that if a device is added in one language, it is also added in another language, otherwise we will quickly find ourselves with developers filling out one language and not the other and the list will be desynchronized!

What do you think?

Personally, I am rather in favor of proposal 2) and 3), I think that 1) requires too complex work and will make the UI heavy everywhere in the services.

If you have ideas and wish to propose a PR for this, it will be with pleasure :slight_smile:

109

It’s also important to consider that some devices may be managed by different services, such as Xiaomi devices that can be used with the xiaomi or zigbee2mqtt services. The development status may not be the same, so some devices may be compatible with one service but not the other, 


That’s why it may be complicated to display this at a global level.

Unless we create a table with the hardware on the rows and the services on the columns. But this table may grow rapidly with development.

110

We will have the same situation with flashed and non-flashed Sonoff devices.
They will work for one service and not the other.
Unless there is a single service for all Sonoff devices.

Options 2 and 3 seem good to me, I agree with @pierre-gilles
A document in the form of a multi-column table:

  • brand
  • product name
  • an image (optional)
  • product protocol
  • type: buttons, lamp, sensor, camera, actuator
  • the service that makes it work in Gladys
  • development (color scheme: green ok, orange in progress, red not yet)
  • a purchase link (not convinced because the link may be dead, which happens with Jeedom)

I already knew it, but you can immediately see why next to the pseudonym of @pierre-gilles, it says Leader.
With a small comment, you can visualize how to implement it graphically and architecturally, so that it is viable and functional for everyone.

111

I would like to add my support to the comments made by @Reno and @Tlse-vins.
I believe that this catalog should not be created at the service level, but rather allow the device to be linked to multiple services.

This page is going to be huge :wink:

113

Yes and no, I understand your point of view, however you currently have sites that allow for very good translation such as for example deepl. I recommend it, it’s an excellent translation site much more powerful than google translate.

Then yes you do all languages and yes some translations may be bad! So a person can very well come and propose a PR to correct the translation.

I don’t think it’s too much of a handicap in my opinion. Especially since it can be done at the very end of the dev.

114

@Tlse-vins I agree with the attribute list, it seems good to me.

Now we need to see where in Gladys this could be accommodated. I’m having trouble seeing where we could fit this for now
 In fact, I’m even wondering if it makes sense to have this in the product, I don’t see where we could put this without overloading the interface with something that is not necessarily useful on a daily basis:

:right_arrow: Maybe this only belongs in the documentation?

Absolutely, we can indicate the list of compatible services in the table.

This, on the other hand, is a more global philosophical question about translations in Gladys. It’s the same problem with the UI: when you develop a feature, you provide translations in which languages?

My opinion is quite clear on this: all languages on which we communicate must be supported, everywhere. I would not accept a PR that does not support the languages on which we communicate, otherwise the UI will be broken everywhere and it makes no sense to say that we manage this language.

You’re talking about German, honestly unless one day we have someone very involved in the project who speaks German and is involved on a daily basis for several months, then yes we will consider German, but otherwise no. Adding a language is very simple, but maintaining a language is a daily job, because translations change several times a day.

This is the philosophy of Gladys 4: we do few things, but what we do we do well.

So don’t worry, there will only be EN and FR to manage.

116

Yes, he is still working on it, finding the right color picker.

117

We’re discussing it here

118

I continue all my UX work on Gladys 4!

Following the feedback I received, yesterday I worked on the « chat Â» view of Gladys.

I improved the design of the empty state:

24
242880×1252 181 KB

And I worked on the message sending process, so that when the connection is not great, the message is in a « sending Â» state before being published:

14
141629×418 6.51 KB

In addition to that, I solved the problem of messages not being in order when sending.

Edit: Ah, and especially thanks to the work of @bertrandda, we moved to Preact X on Gladys 4!! :rocket:

This is not done yet :slight_smile:

120

The best would be to be able to choose by integrations whether the user has access or not.

121

Actually, the multi-user part is not ready yet: nothing has been done :slight_smile: That’s why there’s no interface! All the issues you encountered are just due to the fact that it’s still in development. It’s one of my current priorities along with Z-Wave.

123

Hello!

Does anyone have the roadmap for the launch of Gladys 4 :smiley: ?

Thanks in advance :slight_smile: