Amélioration historique des données des appareils par granularité

[Terdious]

Amélioration de la gestion de l’historique des données des appareils : Intégration d’une granularité configurable pour l’enregistrement des états

Bonjour à tous,

Je souhaite proposer une amélioration visant à optimiser la façon dont Gladys Assistant gère et stocke l’historique des données reçues des appareils connectés. Actuellement, chaque état transmis par un appareil pour une fonctionnalité donnée est enregistré en base de données, indépendamment de son changement ou non par rapport à l’état précédent. Cette méthode, bien que fiable pour la conservation des données, peut conduire à une accumulation rapide de données redondantes, surtout pour des appareils communiquant à des intervalles courts.

Problématique Actuelle : Dans le contexte actuel, un appareil envoyant ses données toutes les 30 secondes entraîne l’enregistrement de chaque donnée reçue, même si celle-ci n’a pas évolué. Cela peut rapidement saturer la base de données avec des informations peu utiles, surtout pour des données qui nécessitent une granularité moins fine (par exemple, l’humidité ou le niveau de batterie qui varie peu).

Proposition : Je propose de permettre une configuration plus flexible de la granularité d’enregistrement des états pour chaque fonctionnalité d’un appareil. Cela pourrait se faire de deux manières :

1. Ajout d’un paramètre global dans les réglages système permettant de définir une période durant laquelle, si les données n’ont pas varié, elles ne seraient pas enregistrées en base de données. Cette période pourrait être ajustée selon les besoins de l’utilisateur ou laissée vide pour maintenir le comportement actuel (enregistrement systématique). Assez simple à mettre en place.
2. Ajout d’une colonne spécifique dans la table t_device_feature pour définir la granularité d’enregistrement par fonctionnalité. Cela offrirait une flexibilité maximale, permettant d’ajuster la fréquence d’enregistrement en fonction de la nature et de l’utilité de chaque donnée.

Avantages :

• Réduction significative du volume de données stockées, en ne conservant que les informations essentielles.
• Optimisation des performances de la base de données, en limitant le nombre d’écritures.
• Personnalisation accrue pour l’utilisateur, qui peut adapter le comportement de l’enregistrement selon les spécificités de son installation domotique.

Exemple :
J’ai installé un thermostat il y a seulement 1 semaine. Je souhaite le supprimer :

Il a déjà 280.000 valeurs alors qu’il ne poll que toutes les 2 minutes. Et la plupart des valeurs sont identiques. Cela réduirait de 4 fois au moins le nombre de données (soit 70.000 environ).

[cce66]

@Terdious

Perso je trouve que les 2 solutions sont les meilleures, avoir le global et la colonne spécifique !
Il serait bien de pouvoir sans passer par zigbee2mqtt de pouvoir fixer les valeurs de fréquence d’envoi des données dans les capteurs depuis Gladys aussi (mon système est ko pour le moment mais il me semble que c’est paramétrable l’envoi des données dans les capteurs pour certains capteurs)

Diantre j’ai voulu voter mais pas trouvé où libérer un vote je suis au taquet, si quelqu’un peut m’aider (suis en mode quiche en ce moment, ça m’ennnnerves ! )

[Terdious]

Merci @cce66 pour ton retour sur la question !

@pierre-gilles, aurais-tu un avis sur la question ? Notamment pour le choix des solutions proposées ?
L’une ? L’autre ? Les 2 ? Autre(s)

[pierre-gilles]

Salut @Terdious

C’est pas la première fois que j’entend ce sujet

Mon avis n’a pas beaucoup changé, je trouve que les deux solutions complexifient le produit et ne sont pas des bonnes solutions :

• Sauvegarder plusieurs fois une même valeur, cela reste de l’information, ce n’est pas inutile.
• Si vraiment il y a un souci de stockage, alors c’est juste un cache misère d’autres problèmes. Autant corriger les autres problèmes.

@Terdious

J’ai installé un thermostat il y a seulement 1 semaine, Il a déjà 280.000 valeurs.

Ok, c’est clairement un souci de l’intégration Netatmo alors. Il faut revoir le fonctionnement. Est-ce que tu peux créer un sujet spécifique et qu’on étudie ce cas précis ? Je veux toute les datas sur ce sujet pour comprendre comment un appareil peut créer 280k valeurs en 1 semaine.

[Terdious]

@pierre-gilles

Mon avis n’a pas beaucoup changé, je trouve que les deux solutions complexifient le produit et ne sont pas des bonnes solutions :

@Terdious

Je propose de permettre une configuration plus flexible de la granularité d’enregistrement des états pour chaque fonctionnalité d’un appareil. Cela pourrait se faire de deux manières :

Relis bien la proposition. La proposition ne nécessite rien par rapport à aujourd’hui. Si un utilisateur ne s’intéresse pas à cette fonctionnalité/possibilité, il n’a rien à toucher.
Il est juste question de pouvoir le faire par nécessité / intérêt.

Tu sais que je suis un gros utilisateur. Et je suis énormément intéressé par la data et l’historique (on avait eu avec @VonOx pendant et à la suite d’un de tes lives une conversation sur comment pouvoir visualiser les datas complètes avec par exemple un outil externe comme ElasticSearch).

@pierre-gilles

Sauvegarder plusieurs fois une même valeur, cela reste de l’information, ce n’est pas inutile.

• Je suis persuadé que c’est de l’information inutile en base pour 90% des features lorsque cette donnée ne change pas. Mise à part avec du webhook, le but de faire du polling « sauvage » (30s à 5 minutes) c’est de pouvoir capter les changements. Et la plupart des appareils fonctionnent par polling, pas par webhooks.

@pierre-gilles

Si vraiment il y a un souci de stockage, alors c’est juste un cache misère d’autres problèmes. Autant corriger les autres problèmes.

• Je ne pense pas que ce soit un cache misère que de pouvoir choisir la data nécessaire à sauvegarder avec un peu plus de granularité. Dans de nombreux cas, les données qui ne changent pas ne sont nécessaire qu’à l’instant T pour avoir un retour sur un problème de retour de donnée / du capteur.

@pierre-gilles

k, c’est clairement un souci de l’intégration Netatmo alors. Il faut revoir le fonctionnement. Est-ce que tu peux créer un sujet spécifique et qu’on étudie ce cas précis ? Je veux toute les datas sur ce sujet pour comprendre comment un appareil peut créer 280k valeurs en 1 semaine.

Ce n’est pas nécessaire, il n’y a aucun soucis, comme je l’ai précisé, le poll est de 2 minutes, mais avec des appareils possédant 8 fonctionnalités et avec une récupération lors de redémarrage il peut arriver d’enregistrer beaucoup de valeurs. Mais cela ne change en rien le sujet évoqué.

Pour quelqu’un qui a déjà 100 appareils avec au bas mot 3 fonctionnalités (c’est régulièrement plus) et un polling moyen de 2 minutes (souvent moins) on est déjà à pas moins de 216.000 state par jours. Si comme moi on souhaite garder les datas en tout temps… on stocke clairement de la datas pour rien. ^^

Mais en effet ce serait intéressant d’avoir plus de retour d’autres personnes sur le sujet !!

[cce66]

@pierre-gilles

Sauvegarder plusieurs fois une même valeur, cela reste de l’information, ce n’est pas inutile.

Si les données n’évolue pas ou est l’intérêt d’enregistrer ces non-évenements du moment qu’il y a une remontée à un intervalle définissable par l’utilisateur comme quoi le lien n’est pas ko ?
Enregistrer toutes les données peut être utile en cas de levée de lièvre sinon…sauf si l’agrégation ensuite diminue la taille de la db en expurgeant ces données inutiles !

Beaucoup de capteurs sont à piles (cr2032 pour la plupart) et si on peut limiter leurs usures cela a du sens que de vouloir limiter le bavardage inutile du capteur !

Ne pas vouloir faire l’usine à gaz type Jeedom, HA est une bonne chose clairement mais perdre en souplesse de paramétrage peut gêner voire rebuter dans certains cas, non ?

[Jluc]

Bonjour,
Ce n’est pas le sujet mais compte tenu du nombre de valeurs générées, je me dis que c’est dommage de ne pas pouvoir les ressortir dans des graphiques horaires ou journaliers dans l’historique. Je profite donc de l’occasion pour relance la demande de fonctionnalités " Récupération de graphiques et de leurs valeurs sur 24 heures depuis des périodes antérieures"

[pierre-gilles]

@Terdious Pour moi c’est un problème dans l’intégration Netatmo.

Effectivement, si le poll va chercher un état et qu’il l’enregistre toutes les 2 minutes alors qu’il n’y a pas réellement de nouvelle état, ça ne sert à rien de l’envoyer à Gladys. Mais c’est à l’intégration Netatmo de faire sa tambouille, Gladys ne peut pas savoir la différence entre un « vrai état » et un « état dupliqué », alors que l’intégration Netatmo si.

Que renvoie l’API Netatmo ?

Pour moi, il faut que tu regarde dans la data renvoyée si il y a un moyen d’identifier un état de manière unique, et ensuite dans ton code Netatmo ça doit être :

if(lastValueNetatmo > lastValueGladys) {
     this.gladys.event.emit(EVENTS.DEVICE.NEW_STATE, {
         device_feature_external_id: feature.external_id,
         state: readValues[feature.category][feature.type](room.open_window),
     });
}

Edit: Bon, je suis allé voir l’API Netatmo, et c’est dedans !

Dans chaque call API tu as le « last_message » qui est à mon avis ce qu’on recherche

Compares juste le last_message venant de Netatmo et le last_value_changed côté Gladys, et hop c’est bon tu n’enregistre que les nouvelles valeurs.

Ca se fait en quelques lignes de code, c’est transparent pour l’utilisateur, et ça répond exactement au problème, et surtout sans retirer les états de mêmes valeurs à différent horaires. 15°C à 9h != 15°C à 10h

Tu en penses quoi ?

[Terdious]

@pierre-gilles, je suis désolé mais je réitère que cela est en dehors du sujet. Ma question se pose pour l’ensemble des appareils. De toute technologies. J’ai des appareils bien pire que Netatmo. Et pour autant dans certains cas, cela est nécessaire. Bien sûr je préférerais seulement sur changement de valeur ET 1 seule datas toutes les 10 minutes par exemple pour signaler que l’appareil fonctionne. Mais convenons en, aucun appareil ne fait cela. Sauf dans le cas d’un polling de Gladys et qui ne le ferait que pour un device complet, pas fonctionnalité par fonctionnalité. Et dans ce cas, il faut bien faire un choix de durée, cela n’enlève rien au donnée identique « pouvant être considérée par l’utilisateur comme inutile ».

Aparté concernant Netatmo :
Oui l’API Netatmo transmet toutes les infos qui permettent de très bien gérer tous les cas de figures

@pierre-gilles

Ca se fait en quelques lignes de code, c’est transparent pour l’utilisateur, et ça répond exactement au problème, et surtout sans retirer les états de mêmes valeurs à différent horaires. 15°C à 9h != 15°C à 10h

Ceci ne résout donc aucun soucis, puisque :

• Les vannes fournissent une valeurs de mesure réelle toutes les 2 minutes (d’où le polling de 2 minutes mis en place)
• Les stations météo toutes les 5 minutes.

Et le sujet est bien là :

• Oui il est intéressant de savoir qu’il fait toujours 15°C, mais peut-être que pour mon usage (tout utilisateur je parle) il serait « suffisant » ou plus opportun que je ne conserve que les valeurs identiques toutes les 10 minutes, voir toutes les 30 minutes. Toutefois il est important pour mes scènes et pour mon historique que le changement soit visible toutes les 2 minutes.
• Mais alors pour la batterie (donnée qui arrivera en même temps) il peut être intéressant de savoir toutes les 2 minutes si celle-ci à changer. Par contre si elle est à 23% depuis toujours 3 jours, je me moque complétement de savoir que pendant 3 jours toutes les 2 minutes elle est restée à ce niveau. Ce qui est important pour moi c’est de savoir :
  • Que pendant 3 jours elle n’a pas baissée à vitesse grand V (changement de valeur)
  • Que pendant 3 jours la data est bien arrivée (last_value). A la limite 1 point par jour à 23% serait « sympa »

Et dans ton exemple comme tu le dis à ce jour tu n’autoriserais pas (et j’en conviens) de faire sauter la valeur sans l’accord de l’utilisateur, peut-être que certains seront intéressés par cette valeur.

Alors par contre oui, en effet pour la station météo, je peux repousser la maj seulement toutes les 5 minutes.

Mais la question reste la même pour certaines data que ce soit toutes les 2 minutes, toutes les 5 minutes ou toutes 1h.

Retour sur le sujet initial concernant l’ensemble des fonctionnalités :

Par exemple ici (vanne en zigbee), j’ai 2 valeurs dont l’historique précis m’intéresse mais pour la batterie par exemple, la datas qui ne bouge pas me pollue.
Et avec la proposition cela ne m’empêcherais de savoir que ce device est toujours disponible. Je serais content de savoir qu’il est passé à 96% dans 5 jours. Mais pendant ces 5 jours, j’aurais 1440 datas inutile dans ma DB. Il en va à peu près idem pour l’intensité même si il peut toujours être intéressant de savoir que l’intensité du signal varie beaucoup.

Autre exemple très concret :


Chez Sonoff, le relais/capteur => Tasmota. J’ai besoin d’un suivis de consommation, notamment à notre époque, pour étudier la consommation après un laps de temps, comparer avec ma production solaire, etc. Dans ces 5 données, certaines n’évolues que très peu, certaines, sont nécessaire pour les scène, certaines pour l’historique. Toutefois la majorité ne m’intéresse pas à conserver pour chaque valeurs identiques. D’autant plus que nous sommes à un poll de 1 minutes (très intéressant pour les scènes notamment liées au solaire) mais alors on peut dire que 75% des datas sont inutiles => 5 features * 60 minutes * 24 = 7200 datas par jours !! Et ce genre d’appareils j’en ai partout et dans ma domotique, dans mes achats pour réduire ou optimiser ma consommation j’en ai un vrai besoin.

Ce que je veux dire c’est que les usages sont divers et variés. Oui avec un capteur de mouvement on est pas trop embêté. Oui avec une lumière ou un équipement qui n’envoit des données que aux changements d’état, on n’est pas embêté.

Mais je suis persuadé qu’avec ce genre d’optimisation, Gladys aurait un vrai plus comparé aux autres produits. On peut même souligné le côté environnemental (stockage local / backups / énorme allègement des requêtes en base de donnée).

Mais pour le moment ce n’est que mon avis. Je poursuis les nettoyages récurrents en DB pour supprimer ces données à fréquences régulières => Contraignant.

[StephaneB]

Pour apporter ma petite pierre à la discussion : je rejoins l’analyse de @Terdious sur le fait qu’il peut être à la fois intéressant de recevoir dans Gladys des données d’un capteur de manière très régulière (pour s’assurer que tout fonctionne, et qu’une valeur n’a vraiment pas changé (et que ce n’est pas dû au capteur qui n’enverrait plus d’info)), et en même temps de ne pas conserver l’intégralité des valeurs en base de données si on veut en maitriser sa taille sur le long terme. Et de pouvoir le régler capter par capteur, car les fréquences seront variable selon le type de capteur et ce qu’on veut en faire…

Après, on est clairement dans ru réglage poussé avec des options qui pourraient surcharger l’interface pour l’utilisateur ‹ standard ›, donc ça pourrait être un paramètre de Gladys à activer volontairement par un utilisateur expérimenté, et qui ne complexifie l’interface de configuration des capteurs que pour lui, s’il l’a choisi.

[Terdious]

@StephaneB

Après, on est clairement dans ru réglage poussé avec des options qui pourraient surcharger l’interface pour l’utilisateur ‹ standard ›, donc ça pourrait être un paramètre de Gladys à activer volontairement par un utilisateur expérimenté, et qui ne complexifie l’interface de configuration des capteurs que pour lui, s’il l’a choisi.

Tout à fait, j’insiste vraiment sur le fait que je sois conscient de cela et que le but n’est pas du tout d’alourdir. Une option dans les paramètres globaux seulement à la base permettant d’accéder à ce genre de paramètrage feature par feature ensuite.
Et ce paramètre ne sera même pas vu pas plus de 50% des utilisateurs, n’ayant réellement aucun impact, conscient qu’une domotique dans un appartement n’a pas les mêmes besoin que dans une maison avec terrain.
Toutefois, cette option pourra être intégralement expliquée dans la documentation, mais surtout pourra être présentée sur le forum lorsqu’une question sur le sujet sera posée.
C’est je pense également le genre d’option qui peut être mise en avant pour de la « publicité ». Oui Gladys est user friendly et soucieuse de la sécurité des données personnelles mais également la question de la légèreté du stockage des données tout en gardant un maximum de visibilité sur la consommation continue.

[pierre-gilles]

Je serais curieux d’avoir tes sources pour la fréquence de rafraichissement des données chez Netatmo !

De ce que lis sur d’autres forums c’est toutes les 10 minutes :

(Source: Netatmo weather: configure update frequency or get max values - Feature Requests - Home Assistant Community)

Ils parlent aussi de « terms of service », donc il faudrait vérifier que le « toutes les 2 minutes » qui est dans l’intégration Gladys actuelle, ça n’est pas contre les ToS de Netatmo.

Pour revenir au sujet initial, pour moi cela reste un sujet qui est clairement lié aux intégrations qui font du polling.

Je comprend le souci de l’intégration Netatmo, mais je ne suis pas entièrement d’accord avec la solution.

@Terdious peut-être qu’un court appel me permettrait de mieux expliquer ce qui me gêne dans ta solution ? Dispo en fin de matinée de 10h45 à 11H si tu veux. Où sinon en asynchrone ici, mais je sens que le débat s’embourbe et prend trop de temps.

[Terdious]

@pierre-gilles

Je serais curieux d’avoir tes sources pour la fréquence de rafraichissement des données chez Netatmo !

De ce que lis sur d’autres forums c’est toutes les 10 minutes :

Salut @pierre-gilles,

Merci pour ta réponse !
Et bien j’ai la chance d’avoir une grande partie des équipements et surtout de pouvoir mettre les mains dans le bouiboui ^^
Donc mes sources sont mes datas tout simplement (j’avais trouvé l’histoire des 2 minutes il y a 2 ans, mais je ne retrouve pas en effet - j’ai l’impression que Netatmo ne communique plus dessus - qui m’avait fait faire les tests sur ce time)

Regarde les dates de tes articles (2020 / 2022), je les avais consultés en effet !! Il est principalement question de la station météo (dont je t’ai notifié les 5 minutes plus haut), et ils parlaient déjà à l’époque d’une possible évolution pour passer de 10 à 5 minutes.

Concret :

• Energie - Qualité de signal RF Thermostat
  

  
  
  
  
  
  On constate bien une valeur différente toutes les 2 minutes

• Station météo intérieur - CO2 car peut bouger pas mal (10 minutes sur tes sources - 5 minutes normalement) :
  

  
  
  
  
  
  Changement de 866 à 842, puis 4 minutes 10 s’écoulent et on passe à 823 (donc on est pile poil à 5 minutes puisque le changement de data à pu se produire entre les 44s qui se sont écoulées pour le passage de 866 à 842 => On a 3 datas différentes en 4 minutes 51s …

• Station météo - Anémomètre Qualité signal RF (la distance le fait fluctuer) :
  

  
  
  
  
  
  On peut constater qu’en 7 minutes la valeur à fluctuée sur 5 valeurs (8 valeurs enregistrées ici), sur ce laps de temps j’ai redémarré à plusieurs reprises. Pour le coup on est bien en dessous des 5 minutes (je ne l’explique pas mais les datas le révèle)

@pierre-gilles

Je comprend le souci de l’intégration Netatmo, mais je ne suis pas entièrement d’accord avec la solution.

Je suis désolé, mais j’insiste sur le fait qu’il n’y a pas de soucis avec l’intégration Netatmo en particulier, le « soucis » (attention je ne confond pas, ce n’est pas un bug dans ma tete ^^) est réel dans de nombreux cas (ci-dessous zigbee / sonoff)

@Terdious

Par exemple ici (vanne en zigbee), j’ai 2 valeurs dont l’historique précis m’intéresse mais pour la batterie par exemple, la datas qui ne bouge pas me pollue.

@Terdious

Chez Sonoff, le relais/capteur => Tasmota. J’ai besoin d’un suivis de consommation, notamment à notre époque, pour étudier la consommation après un laps de temps, comparer avec ma production solaire, etc.

@pierre-gilles

@Terdious peut-être qu’un court appel me permettrait de mieux expliquer ce qui me gêne dans ta solution ? Dispo en fin de matinée de 10h45 à 11H si tu veux. Où sinon en asynchrone ici, mais je sens que le débat s’embourbe et prend trop de temps.

Si tu es dispo, avec grand plaisir !

[pierre-gilles]

Petit message pour récapituler notre call @Terdious C’était chouette de s’appeler pour clarifier un peu tout ça !

• Je pense que c’est aux développeurs d’intégrations de mettre en place les bons mécanismes pour que leur intégration ne soient pas « trop agressives » sur la quantité de donnée qu’elles envoient à Gladys.

Dans le cas de Netatmo, je suis pour faire du cas par cas dans le code.

Exemple: Feature « batterie »: max 1 point par 30 minutes si pas de changement de valeur.

L’objectif est que nous trouvions les bonnes limites qui soient les plus précises sans compromettre la taille de la DB, ni les performances de Gladys.

Pour l’utilisateur, c’est transparent et ça fonctionne automatiquement, dans la philosophie du projet.

• Sur le moyen terme, je suis de très près DuckDB, une base de donnée fichier (comme SQLite) mais adaptée aux données time-series. L’idée ne serait pas de remplacer le SQLite de Gladys ( qui est tout à fait adapté au reste de Gladys ), mais uniquement de transférer nos données time-serie sur un fichier dédié. D’après mes tests, la réduction en taille de DB pour des performances supérieures à ce qu’on fait actuellement est assez phénoménales ( Cf : Gestion plus fine de l'historique des états - #18 par pierre-gilles )

Pour l’instant je suis en stand-by sur ce développement car ils sont encore en beta (0.10.0), à voir si eux se considèrent comme « production-ready » ou pas.

[lmilcent]

J’ai hate, ma DB fait 22Go, je vais faire du ménage

[lmilcent]

J’ai passé la rétention de « illimité » à « 6 mois » et lancé un nettoyage.
Ma base faisant 22 Go, j’ai constaté que le fichier .wal est passé à 15 Go et a fait planté la tâche de nettoyage car le disque était plein.

Est-ce que la tache de nettoyage pourrait faire en batch, avec un vacuum entre temps, pour éviter cette situation ?
Je fais une demande de fonctionnalité ou pas @pierre-gilles ?

[pierre-gilles]

@lmilcent

Est-ce que la tache de nettoyage pourrait faire en batch, avec un vacuum entre temps, pour éviter cette situation ?

La tâche de nettoyage fonctionne déjà en batch.

Le VACUUM est une tâche très très lourde, et bloquante qui peut prendre jusqu’à 10h sur les disques lent, donc c’est pas réaliste de la lancer automatiquement… il faut que ce soit à la demande de l’utilisateur

[pierre-gilles]

Pour info, j’ai contacté la communauté DuckDB sur leur Discord:

[pierre-gilles]

Je n’ai pas eu de réponses de DuckDB, en revanche j’ai trouvé les réponses à mes questions dans une vidéo d’un talk fait par DuckDB le mois dernier

La v1 sortirait en premier semestre 2024, soit d’ici juillet théoriquement (sauf retard).

D’après le talk :

It’ll be focused on stability and robustness
We just want to make sure that this is a DuckDB release that you can deploy on a satellite and fly to Venus without having to worry about patching your DuckDB instance

C’est très rassurant car c’est exactement ce que nous recherchons pour Gladys : un soft tellement stable qu’il peut tourner 10 ans sans corruption et sans intervention humaine.

La compatibilité backward est nécessaire pour Gladys (pour pouvoir faire des mise à jour), et donc c’est très positif que ce soit dans leur objectif pour la v1.

Le talk :

State of the Duck (DuckCon #4, Amsterdam, 2024)

Bref, tout ça c’est hyper positif. Pour moi DuckDB est le futur de Gladys si tout ce qu’ils promettent est vérifié J’ai déjà fais des tests, et c’est vraiment très très cool.

Néanmoins, cet objectif ne doit pas nous bloquer sur les autres points qu’on avait identifié plus haut dans cet discussion:

Amélioration historique des données des appareils par granularité

Petit message pour récapituler notre call @Terdious C’était chouette de s’appeler pour clarifier un peu tout ça ! Je pense que c’est aux développeurs d’intégrations de mettre en place les bons mécanismes pour que leur intégration ne soient pas « trop agressives » sur la quantité de donnée qu’elles envoient à Gladys. Dans le cas de Netatmo, je suis pour faire du cas par cas dans le code. Exemple: Feature « batterie »: max 1 point par 30 minutes si pas de changement de valeur. L…