HC3 & HC3L - 5.200.8 - STABLE - 18/12/2025

[Lazer]

Firmware 5.200.8

STABLE

18/12/2025

 

 

Thank you for using our gateway! Be sure to update to the latest version to enjoy new features and improvements.

 

What's new:

 

Access

    Fixed error when deleting users.    

 

Devices

    The "Save to Event Panel" checkbox has been fixed to prevent data from being saved.
    Added support for cooling mode for the Thermostat & Climate Zone plugin.
    Curtain track device integration with the role "curtain" set in the system.
    Added a mechanism to prevent the possibility of adding custom icons with different extensions for one device.
    Updated translations for Heat Activator plugin.
    Removed battery indication support for some devices with old firmware that do not support battery reporting.

 

Network

    It is possible to turn off WiFi when an external USB ethernet adapter is connected.

 

Nice*

    BiDi-EVB Hirschmann (TT1NBDEVB) device support.
    Preserved the parameter value after the binding process for BiDi interfaces.
    The current battery level of the devices is retrieved immediately after the pairing process.
    Added support for battery level indication for new firmware of Next Solar tubular motor.

 

Other

    Improved system performance for larger configurations containing connected Hubs.
    Fixed the autocomplete suggestion list in the search field for Other devices.
    Removed category selection when creating rooms.

 

Quick Apps

    Added the ability to disable one log channel in Quick Apps using a dedicated function.
    SNI TLS extenson support for MQTT protocol.

 

Scenes

    Added an option to define title to email notifications called from Lua (Quick Apps and scenes).

 

Users

    Users removed from the Hub do not function as VoIP users.*
  

Z-Wave

    Updated parameters templates for MCO thermostats. 
    Added additional (optional) parameter to force direct communication for the device update procedure for Z-Wave 2.0.
    Optimized the operation of the Z-Wave Device Update tab by adding a loading mechanism for devices in the reading/processing state.
    Added the ability to select the Hub for resetting the Z-Wave network.**
    Updated Z-Wave SDK to 7.21.7 GA.***

 

Bug Fixes:

 

Access

    Fixed the problem of logging out the Advanced User from some interface tabs in the absence of some permissions.

 

Climate panel

    Fixed errors that occurred when setting the Off mode in the Climate Panel schedule.

 

Devices

    Fixed the issue where Nice Camera plugin doesn't show any video with the low res option enabled.
    Fixed calibration settings for FGD-223 (DoubleDimmer-Control), minimum value cannot be set higher than maximum.
    Fixed DSK code display when pairing devices, all numbers are visible.
    Fixed activity of the update verification button in the Z-Wave devices Update tab.
    Fixed the redundant display of the message about the unavailable dimming option in the FGD-223 (DoubleDimmer-Control) device configuration wizard.
    Fixed the ability to download a template for the FGD-223 (DoubleDimmer-Control) device.
    Fixed roller shutter status updates in the user interface.
    Fixed error 502 when changing parameters of the FGD-223 (DoubleDimmer-Control) device.**
    Fixed icon display for remote controls during binding wizard in Yubii App.
    Fixed issue with moving to the next step after 60 seconds when adding devices.
    Fixed operation of the Z-Wave device software update queue.
    Fixed values sent for the slider when testing the FGD-223 (DoubleDimmer-Control) device.
    Fixed problems with setting parameters for channels of the FGD-223 (DoubleDimmer-Control) device in some cases.
    Fixed rare save issues for the On/Off mode of the FGD-223 device (DoubleDimmer-Control).
    Fixed some translations of the Heat Activator plugin for the Polish version.
    Fixed redundant battery status notifications and their translations.

 

Energy Panel

    Fixed the appearance of the date field for the Energy Panel in the panel settings.

 

Gateway connection

    Fixed Slave device role setting after factory reset.
    The configuration description for slave devices in the Connect Gateway tab has been corrected.
    Fixed setting favorite positions for Bi-Rec lightining devices in Gateway Connection setup.
    Styled the authentication screen for the slave device.

 

Nice*

    Fixed the display of binding mode selection options for Nice devices in the mobile application.
    Fixed control of venetian blinds when using BiDi-Shutter and BiDi-Awning modules.

 

Other

    Fixed display of text with icons in Profiles.
    Fixed LED behavior according to the device manual.*
    Fixed graphic quality on the login screen.
    Fixed the issue of the disappearing date header for notification groups when deleting at least one notification from a given day.
    Fixed sorting for some notifications in the notification panel.
    Fixed an issue with the use of an outdated password reset email template for some languages.
    Minor UI/UX fixes.

 

Quick Apps

    Fixed dropdown refresh in Quick Apps.
    Reduced spacing under buttons in Quick Apps.
 

Scenes

    Fixed the appearance of percentage sliders in block scenes.
    Fixed the scenario editing icon to be more visible.
    Removed installer email selection for send picture to user option in block scenes.
    Added missing parameters for thermostats in scenes.
    Fixed the display of the scene list in the interface for the Norwegian language.

 

Update

    The update file is deleted on checksum error so that it can be downloaded again.

 

Users

    Fixed the display of a language settings error when changing the language before logging in as a standard user.
    Advanced User has no rights to full-screen camera preview.
 

Z-Wave

    Devices from the Slave Hub are correctly removed when the Z-Wave network is reset on the Master device.
    Everspring ST814 device model for Z-Wave 2.0 and Z-Wave 3.0 engines has been made consistent.
    The operation of the Z-Wave "End learning mode" button has been fixed, the mode is now ended correctly.

Known issues:

Z-Wave Engine 3.0

    Some Z-Wave devices are not fully compatible with the new version of Z-Wave engine.

* - Does not apply to HC3L (Home Center 3 Lite).
** - Applies only to Z-Wave 3.0 engine.
*** - Applies to hubs using Z-Wave 700 series chip.

 

Security:

    Hidden information regarding some of the camera configuration for Installers.
    Some cipher suites for TLS that are no longer recommended have been disabled.
    Updating sudo to a higher version.

[chrisalex]

bonjour,

 

savez vous comment trouver l'info de la  syntaxe pour cette amélioration ?

 

Citation

 

Scenes

    Added an option to define title to email notifications called from Lua (Quick Apps and scenes).

 

 

[Lazer]

Oui, voir ici sur le sujet de la précédente Beta :

 

 

 

Je recopie le contenu ici, comme cela a été documenté par Fibaro dans un post dédié sur le forum officiel :

• https://forum.fibaro.com/topic/79587-update-5191-beta-crucial-changes-for-api-scenes-and-quickapps/

 

Here are the key changes in API, scenes and QuickApp that the new version offers.

 

1. Added an option to define title to email notifications called from Lua (Quick Apps and scenes).

 

The email subject could be customized by adding an optional parameter to the method for sending an email to users:

 

In case of LUA Scenes:

hub.alert("email", {userId}, emailBody, false, emailSubject)

 

In case of Quick Apps:

hub.alert("email", {userId}, emailBody, emailSubject)

 

2. Added the ability to disable one log channel in Quick Apps using a dedicated function.

 

Quick App log level can be set using following assignment in the LUA code on Quick App:

self.logLevel = log_level

 

where log_level could have one of the following values: NONE, ERROR, WARNING, DEBUG, TRACE.
Example to set Quick App log level to WARNING which will allow only errors and warnings to be displayed in console:

self.logLevel = WARNING

 

3. Added the request to synchronise the sort-order in the system according to administrator configuration.

 

New API endpoint was introduced to synchronize (reset) sorting order of devices and scenes for all users back to the order that is assigned to the admin:

POST /api/sortOrder/syncUsersWithAdmin

Only admin, installer and support are authorized to call that API endpoint.

 

4. SNI TLS extension support for MQTT protocol.

 

LUA MQTT Client that uses TLS by default enables SNI TLS Extension by default since version 5.191. In case of some problems there is a possibility to switch SNI off by the following setting in connection options:

self.client = mqtt.Client.connect(brokerURI, {
    port = 1883,
    tls = {
        useSNI = false
    }
})

 

[Lazer]

Moi c'est cette nouveauté qui m'interpelle :

Il y a 14 heures, Lazer a dit :

Quick Apps

    Added the ability to disable one log channel in Quick Apps using a dedicated function.

Je me demande en quoi ça consiste...

[jjacques68]

MAJ en cours...

 

depuis la précédente update, j'ai du modifié du code...

les instructions suivantes plantaient : 

QuickApp:debug()
QuickApp:warning()
QuickApp:error()

 

que j'ai remplacé par des "self".

j'en avais sur de vieux quickapp... 

[Lazer]

Hum... ça doit être lié à la remarque je fais juste au dessus, mais je ne sais pas encore comment ...

[TitiXsi]

Il y a 6 heures, Lazer a dit :

Moi c'est cette nouveauté qui m'interpelle :

Je me demande en quoi ça consiste...

Mise à part pour éviter qu'une quickapp sature la box de messages si trop bavarde par un bug... A quoi ça sert ?

[henri-allauch]

J'avais aussi cette compréhension à un moment ......    mais dans le texte de l'exemple ils parlent d' Affichage et pas insertion dans les logs   

Cà reste confu .

 

"Example to set Quick App log level to WARNING which will allow only errors and warnings to be displayed in console:" 

 

 

[Sakkhho]

Hello.
Il me semble que j ai pas mal de QA qui plantent depuis la mise à jour de cet après-midi (celle de home assistant entre autre …)
Je dois analyser cela demain sinon je restaurerai.

Vous avez aussi des problèmes de votre côté ?

À+

[henri-allauch]

Je n'ai pas fait cette mise à jour je suis resté sur la stable précédente.

Mais sur le forum officiel il y a quelques problèmes signalé sur le réseau ZWave (Strange logs in Zwave after update) et des devices qui changent d'ID (Devices are removed and added back with different IDs out of nowhere, randomly.)

 

Peut-être y a t'il un rapport avec tes plantages  ?????

 

[TitiXsi]

il y a 25 minutes, henri-allauch a dit :

Je n'ai pas fait cette mise à jour je suis resté sur la stable précédente.

Mais sur le forum officiel il y a quelques problèmes signalé sur le réseau ZWave (Strange logs in Zwave after update) et des devices qui changent d'ID (Devices are removed and added back with different IDs out of nowhere, randomly.)

 

Peut-être y a t'il un rapport avec tes plantages  ?????

 

Alors ça.... C'est peut-être pas terrible... Car si ils sont supprimés et ajouté de nouveaux... Je ne sais pas si on peut restaurer une ancienne sauvegarde... 

[Sakkhho]

Ouch.
Je test demain pas eu le temps ce jour.


Envoyé de mon iPhone en utilisant Tapatalk

[Sakkhho]

Hello

j'ai restauré avec la version précedente et tout refonctionne correctement.

Version stable à fuir donc

[fel-x]

En effet, avec la 5.200.8 il y a plusieurs QA qui plantent en boucle avec ce type de warning ou d'erreur : 

 

[ERROR] [QUICKAPP739]: Unknown error occurred: no static 'logLevel' in class 'QuickApp'

[ERROR] [QUICKAPP740]: Unknown error occurred: no static 'logLevel' in class 'QuickApp'

[WARNING] [QUICKAPP740]: Variable Data Type not found

 

Aucun fichier Lua de ces QA ne fait appel à QuickApp.logLevel ou self.logLevel !!!

C'est vicieux ça comme mise à jour.

Que faire à part un restore ? (je préfère corriger que rétropédaler si possible)

 

[fel-x]

Bon la solution est assez simple : 

ajoutez ceci AVANT onInit() dans le fichier main.lua des QA qui plantent.

Ceci pour éviter toute erreur si Fibaro corrige modifie encore son moteur sans prévenir et sans documentation adéquate :

 

QuickApp.logLevel = 1

 

Modifié il y a 17 heures par fel-x

[fel-x]

D'après Gemini on peut donner la valeur 0 pour supprimer le log ou alors : 

 

 

Valeur	Niveau	Description
1	Error	N'affiche que les erreurs critiques qui empêchent le bon fonctionnement.
2	Warning	Affiche les erreurs + les avertissements (problèmes potentiels).
3	Info	(Par défaut) Affiche les erreurs, warnings et les informations générales.
4	Debug	Affiche tout, y compris les détails techniques de développement (très verbeux).

[Lazer]

Pardon, je vais pousser mon coup de gueule, j'en peux plus des copier/coller des IA sur les forums qui racontent n'importe quoi (= inventer un truc, probable mais approximatif, donc faux)
Que tu utilises l'IA pour tes usages perso aucun problème, mais merci de ne pas venir recopier les erreurs de ces IA sur un forum public (qui servira ensuite à alimenter une IA, qui aura encore plus d'hallucination soit dit en passant... tu vois l'effet pervers)

 

Plutôt que d'avoir ce réflexe de demander à une IA peut être vaudrait-il mieux commencer par lire la doc officielle, pour une fois que Fibaro fait une communication, en plus sur cette même page !!!

 

En occurrence, c'est en majuscule qu'il faut l'écrire, en effet si je prend l'exemple de Warning donné par l'IA, c'est une variable non définie (nil), alors que si on utilise WARNING tel que donné par Fibaro, on obtiens une variable de type number dont la valeur vaut 2.

 

[Lazer]

J'en ai profité pour faire quelques tests.

Il ne faut pas le déclarer globalement comme l'a écris @fel-x plus haut, sinon c'est sans effet sur la suite du code :

QuickApp.logLevel = 1 -- Ne pas faire ça

Parce que dans ce cas on affecte la valeur 1 à la variable logLevel de la classe QuickApp, mais c'est sans effet sur l’instanciation de l'objet quickApp (notez la subtile différence de minuscule sur le premier caractère), hors cet bien cet instance quickApp qui portera tout le code LUA par la suite.

 

Il faut le faire comme décrit par Fibaro, dès le démarrage du QuickApp dans la fonction onInit(), comme ceci :

function QuickApp:onInit()
	self.logLevel = DEBUG
end

Attention, l'objet quickApp n'est pas encore initialisé lors de l'exécution de la fonction onInit(), c'est donc bien uniquement self qu'il faut utiliser pour initialiser la variable logLevel.

 

Et plutôt que d'utiliser des chiffres, c'est mieux d'utiliser les variables prédéfinies en majuscule comme documenté par Fibaro.

Toutefois je remets les correspondances des valeurs numériques ici :

• TRACE = 4
• DEBUG = 3
• WARNING = 2
• ERROR = 1
• NONE = 0

Dans l'ordre numérique inverse, ce qui me semble plus logique, en premier la valeur qui permet d'afficher un maximum d'information dans la zone de debug, et en dernier le plus restrictif, à savoir aucun affichage du tout.

 

Ensuite, le fonctionnement est assez intéressant.
Prenons cet exemple de code, j'ai tout mis dans la fonction onInit(), mais comme déjà précisé seule la définition de self.logLevel doit nécessairement s'y trouver, on peut très bien imaginer que l'affichage des messages peuvent se trouver dans différentes fonctions à la suite du QA :

function QuickApp:onInit()

	self.logLevel = WARNING           -- Affichage des logs de niveau WARNING minimum

	self:trace("self:trace")          -- Pas de message
	self:debug("self:debug")          -- Pas de message
	self:warning("self:warning")      -- Message OK
	self:error("self:error")          -- Message OK

	print("print")                    -- Message OK

	hub.trace(__TAG, "hub.trace")     -- Message OK
	hub.debug(__TAG, "hub.debug")     -- Message OK
	hub.warning(__TAG, "hub.warning") -- Message OK
	hub.error(__TAG, "hub.error")     -- Message OK

end

Ce qu'on constate, c'est que la définition du niveau de log désiré se configure donc dans self.logLevel comme déjà vu, et en conséquence l'affichage des logs se fera ou non pour les différentes fonctions d'affichage de self.xxx().

Je ne sais pas si je suis clair, mais j'ai mis des commentaires dans le code LUA ci-dessus pour comprendre.
Ce qui est logique, puisque qu'on a affecté logLevel à self, donc à l'instance quickApp.
Tandis que les fonctions print() et hub.xxx(), étant en dehors du scope de l'instance quickApp, ne prennent pas en compte le niveau de log choisi : c'est à dire que les messages sont toujours affichés.

Ce mode de fonctionnement est intéressant, car il permet dynamiquement, et très facilement, d'ajuster le niveau de log d'un QuickApp pour déboguer temporairement le code LUA.

 

Exemple concret :

Au démarrage du QA, dans onInit(), je configure un niveau WARNING, donc seuls les messages de niveau supérieur, à savoir WARNING et ERROR seront affichés par défaut.

Sur mon QA, je crée 2 boutons, l'un donc le code LUA permet uniquement de descendre le niveau de log à TRACE, et l'autre de remettre à WARNING.
D'ailleurs on pourrait carrément imaginer l'utilisation d'une liste déroulante vu que c'est disponible depuis quelques temps dans les QA, et ainsi permettre à l'utilisateur de choisir précisément le niveau de log désiré.

Et ainsi, dès que l'utilisateur clique sur les boutons, il peut dynamiquement jouer sur le niveau de verbosité de QA dans la fenêtre de log.
C'est encore plus pratique que la technique que j'utilise depuis le début qui consiste à mettre une variable nommée debug dans les Variables du QA, car sa modification entraine nécessairement un redémarrage complet du QuickApp.

 

Je vais m'atteler à modifier mes prochains QA en ce sens.

[henri-allauch]

Est-ce à dire que si l’on veut conserver l’ensemble des messages log comme avant la mise en place de cette version, il faut ajouter self.logLevel = TRACE dans la function QuickApp:onInit() ?

si oui :

saurait pu être la valeur par défaut pour éviter de modifier tous les QA à la mise en place de ce nouveau firm

[Lazer]

j'ai ajouté l'instruction suivante dès le début de onInit() :

print("self.logLevel =", self.logLevel)

Et on obtient la valeur 4, qui correspond au niveau de log le plus détaillé TRACE.

 

Ce qui signifie que par défaut, si on ne définit rien, ce sont l'ensemble des logs qui sont affichés, comportement identique à avant.

Donc rien à faire pour conserver le comportement par défaut des QuickApp, la rétrocompatibilité est assurée 

 

A la réflexion, ce que je ne comprends pas ce sont les erreurs rencontrées par @fel-x 

Je n'ai aucun QuickApp ayant présenté ce comportement sur ma box de test, donc ce doit être des QuickApps que je n'utilise pas... aucune idée de comment ils ont été codés, mais probablement pas très proprement pour générer ce genre d'erreur.
Ce qui aurait été intéressant que tu regardes, c'est essayer de comprendre l'origine de l'erreur (quelles sont les lignes qui déclenchent les erreurs) plutôt que de demander à une IA de te trouver une solution de contournement, qui n'est pas la bonne en plus....

 

EDIT : sur le forum officiel j'ai trouvé un seul message similaire, qui concerne un QA Velux dispo sur le Marketplace, que je n'utilise pas :

https://forum.fibaro.com/topic/79615-unknown-error-occurred-no-static-loglevel-in-class-quickapp/

 

Modifié il y a 14 heures par Lazer

[fel-x]

Salut,

Je comprends ton coup de gueule @Lazer 

 

Pour le coup, mon info ne venait pas d'une IA mais d'un membre reconnu du forum officiel Fibaro (@jgab)

J'aurais du le noter : 

https://forum.fibaro.com/topic/79616-unknown-error-occurred-no-static-loglevel-in-class-quickapp/

 

Ce n'est qu'après avoir lu la doc Fibaro mentionnée plus haut, et l'avoir testée sans succès (ou alors j'ai commis une erreur?), que je suis parti à la recherche de la réponse sur le forum officiel.

 

Par contre ne trouvant pas l'explication de la valeur "1" j'ai demandé à une IA c'est vrai 

La réponse de l'IA.. je ne l'ai testée qu'avec des valeurs chiffrées et ça marchait aussi. Sinon avant de la coller ici j'aurais noté que les valeurs textuelles ne devaient pas être en minuscules mais en majuscules.

 

Merci de ta correction.

Je vais aller plus loin avec ce que tu as expliqué.

 

 

[henri-allauch]

il y a 16 minutes, Lazer a dit :

 

j'ai ajouté l'instruction suivante dès le début de onInit() :

print("self.logLevel =", self.logLevel)

Et on obtient la valeur 4, qui correspond au niveau de log le plus détaillé TRACE.

 

Ce qui signifie que par défaut, si on ne définit rien, ce sont l'ensemble des logs qui sont affichés, comportement identique à avant.

Donc rien à faire pour conserver le comportement par défaut des QuickApp, la rétrocompatibilité est assurée 

 

Ok ça répond à ma question ci-dessus 

[fel-x]

il y a 19 minutes, Lazer a dit :

Je n'ai aucun QuickApp ayant présenté ce comportement sur ma box, donc ce doit être des QuickApps que je n'utilise pas... aucune idée de comment ils ont été codés, mais probablement pas très proprement pour générer ce genre d'erreur.

Ce sont 3 QA du même auteur :

https://marketplace.fibaro.com/items/openweather-weather-provider

https://marketplace.fibaro.com/items/sma-pv-power-sensor

https://marketplace.fibaro.com/items/sma-pv-energy-meter

 

Je l'ai prévenu personnellement.

Car je ne trouve rien dans son code qui tente de régler le niveau de debug...

 

Une autre QA qu'il a écrite (https://marketplace.fibaro.com/items/velux-active-shutters-integration) a été rapportée avec le même bug, mais je ne l'emploie pas.

 

On est bien d'accord, ce sont uniquement des QA proposées par lui qui plantaient à la mise à jour, et les miennes par exemple, ou GEA en l'occurence n'ont aucun problème.

[Lazer]

Ah, j'avais loupé cette discussion (sur une partie du forum officiel où je ne traine pas...)

 

ça a du sens, car @jang parle justement de l'instanciation de la classe QuickApp.

Cela dit, ça n'explique pas pourquoi l'erreur apparait si le code LUA ne fait jamais référence à la variable QuickApp.logLevel.

 

Je pense que c'est parce que, comme je tentais de l'expliquer plus haut, le code fait des appels pas très conventionnels à des fonctions d'affichage des logs (c'est à dire sans passer par self.xxx(...) ou hub.xxx(__TAG, ...), et c'est à l'intérieur de ces fonctions que l'erreur se produit.

Mais comme ce sont des fonctions proposées par Fibaro, on n'a évidemment pas accès à leur code LUA.

 

Je persiste à penser que c'est du code mal écrit par son auteur (en plus tu confirmes que c'est toujours le même), qui ne doit pas respecter les bonnes pratiques d'écriture de QuickApp à la mode Fibaro, si bien qu'après une mise à jour, ça fonctionne moins bien...

 

J'ai fait une rapide tentative de reproduire le problème chez moi, avec des pcall() pour identifier la ligne qui pourrait poser problème, mais sans succès, je n'arrive pas à reproduire.
En même temps, si on arrive à reproduire, c'est qu'on a trouvé l’instruction problématique et ça sera donc facile à corriger.

Bref, sans se lancer dans un débogage complet du code des QA partagés par son auteur sur le market, la solution de contournement donnée fonctionne, mais je n'aime pas ça, ce n'est pas propre, à mon avis ça ne protège en rien contre de futurs bugs similaires.

Espérons que l'auteur nettoie le code de ses QA.