C’est bizarre que tu n’ais aucune ligne avec ce filtre alors que le serveur répond CONFLICT.
Essaye de regarder la table t_device_feature
Bonjour @cicoub13
j’ai regarder dans la table t_device_feature, il n’y as pas de trace de mon detecteur , donc je pense qu’il a bien été supprimé. Par contre là ou j’ai une doute c’est sur les deux fonctions de luminosité. Elles sont nommées différemment sur Zm2Mqtt et dans gladys elles ont le meme nom, comment je peux voir si c’est le meme lien mqtt?
Bonsoir @pierre-gilles
je viens de voir un probleme dans les « Taches » des parametres de Gladys
j’ai remonté l’historique jusqu’au debut , donc 7 jours de recul, et j’ai trouvé cette erreur qui ce repete tous les jours :
Agrégation donnée capteur horaire
il y a 5 jours
Error: Error
at Database.<anonymous> (/src/server/node_modules/sequelize/lib/dialects/sqlite/query.js:179:27)
at /src/server/node_modules/sequelize/lib/dialects/sqlite/query.js:177:50
at new Promise (<anonymous>)
at Query.run (/src/server/node_modules/sequelize/lib/dialects/sqlite/query.js:177:12)
at /src/server/node_modules/sequelize/lib/sequelize.js:314:28
at async SQLiteQueryInterface.bulkUpdate (/src/server/node_modules/sequelize/lib/dialects/abstract/query-interface.js:366:12)
at async t_device_feature.update (/src/server/node_modules/sequelize/lib/model.js:1958:28)
at async /src/server/lib/device/device.calculcateAggregateChildProcess.js:153:5 {
name: 'SequelizeTimeoutError',
parent: [Error: SQLITE_BUSY: database is locked] {
errno: 5,
code: 'SQLITE_BUSY',
sql: 'UPDATE `t_device_feature` SET `last_hourly_aggregate`=$1,`updated_at`=$2 WHERE `id` = $3'
},
original: [Error: SQLITE_BUSY: database is locked] {
errno: 5,
code: 'SQLITE_BUSY',
sql: 'UPDATE `t_device_feature` SET `last_hourly_aggregate`=$1,`updated_at`=$2 WHERE `id` = $3'
},
sql: 'UPDATE `t_device_feature` SET `last_hourly_aggregate`=$1,`updated_at`=$2 WHERE `id` = $3',
parameters: {}
}
Est ce que mon probleme ne serait pas lié ?
Merci de ta réponse
donc meme avec la V4.37 j’ai le meme probleme
C’est une erreur assez classique quand ton disque n’est pas assez performant pour encaisser le volume de lecture/écriture 
Pas de liens avec ton souci.
Pour installer Gladys, si tu comptes avoir une jolie installation avec pas mal de capteurs, je conseille vraiment d’être sur un bon SSD sur un mini-PC, sinon tu es vite limité. Tu es sur micro-SD actuellement ?
Ce que je recommande c’est le Beelink qui est livré avec un SSD NVMe bien puissant : https://amzn.to/3UQgLkq (actuellement à 199€ grâce au coupon de 60€)
Bonjour @pierre-gilles
Je suis sur un ssd de 120Go deja et un RPI3b+. J’evisage de passé sur un RPI4B que j’ai acheté ? qu’est ce que tu en pense. ça peut le faire ?
la gestion des appareils zigbee a dû etre modifié.
Voici mon detecteur declarée dans Gladys il y a 20jours (apres une restauration de ma BD) :
le voici le meme capteur qui me genere l’erreur :
Avant il n’y avait qu’une foction luminosité, maintenant il y en a 2.
Est ce que quelqu’un peut verifier ça s’il vous plait
Oui il y eu un ajout d’une illuminance il y a 2 mois dans la version 4.33.
Il y a sûrement un lien avec ton problème
Oui, on vient de vérifier c’est bien un doublon !!
Bon d’après la doc zigbee2mqtt du capteur, l’expose est le même pour les 2 illuminances :
Du coup forcément, même selector et même external_id.
Donc tant que je n’avais pas fait de mise à jour le capteur fonctionnait, j’ai une mise a jour , j’ai eu l’erreur . Maintenant que je l’ai supprimé, je ne peux plus l’intégrer dans Gladys
@Terdious
Bon d’après la doc zigbee2mqtt du capteur, l’expose est le même pour les 2 illuminances :
dans zigbee2Mqtt elles sont differentes non?
{
« battery »: 100,
« device_temperature »: 27,
« illuminance »: 6,
« illuminance_lux »: 6,
« linkquality »: 117,
« occupancy »: false,
« power_outage_count »: 173,
« voltage »: 3065
}
En effet ^^ My bad !! Et ton expose côté Gladys le confirme puisque tu as bien une feature avec l’unité et l’autre sans :
| name | Illuminance |
|---|---|
| read_only | true |
| has_feedback | false |
| min | 0 |
| max | 100000 |
| category | light-sensor |
| type | decimal |
| unit | lux |
| external_id | zigbee2mqtt:detecteur_couloir:light-sensor:decimal:illuminance |
| selector | zigbee2mqtt-detecteur-couloir-light-sensor-decimal-illuminance |
et
| 5 | Object { name: Illuminance, read_only: true, has_feedback: false, … } |
|---|---|
| name | Illuminance |
| read_only | true |
| has_feedback | false |
| min | 0 |
| max | 100000 |
| category | light-sensor |
| type | decimal |
| unit | null |
| external_id | zigbee2mqtt:detecteur_couloir:light-sensor:decimal:illuminance |
| selector | zigbee2mqtt-detecteur-couloir-light-sensor-decimal-illuminance |
Ducoup , j’ai ce device là, qui m’a fait la meme, mais a un moment , je ne sais pourquoi , il s’est bien integré.
Comme je connais la technique maintenant je vais pouvoir investiguer
Maintenant il faut attendre qu’un Dev intervienne, je pense, ce n’est pas resovable directement, c’est ça ?
En tout cas un grand merci @Terdious, d’avoir pris le temps de m’aider 
Fiouf j’ai galéré à trouver mais j’ai pu avoir un expose complet du capteur. Je réitère (en modifiant le terme « expose » par « property ») et confirme donc ce que je disais au départ :
Du coup j’ai pu trouver un expose de ce capteur ici : Aqara human body movement and illuminance sensor RTCGQ11LM not reporting battery level · Issue #11616 · Koenkk/zigbee2mqtt · GitHub
On peut voir dans ce dernier :
[
{
"definition": null,
"endpoints": {
[...]
},
"friendly_name": "Coordinator",
"ieee_address": "0x00124b0024cae636",
"interview_completed": true,
"interviewing": false,
"network_address": 0,
"supported": false,
"type": "Coordinator"
},
{
"definition": {
"description": "Aqara human body movement and illuminance sensor",
"exposes": [
{
"access": 1,
"description": "Remaining battery in %",
"name": "battery",
"property": "battery",
"type": "numeric",
"unit": "%",
"value_max": 100,
"value_min": 0
},
{
"access": 1,
"description": "Indicates whether the device detected occupancy",
"name": "occupancy",
"property": "occupancy",
"type": "binary",
"value_off": false,
"value_on": true
},
{
"access": 1,
"description": "Measured temperature value",
"name": "temperature",
"property": "temperature",
"type": "numeric",
"unit": "°C"
},
{
"access": 1,
"description": "Voltage of the battery in millivolts",
"name": "voltage",
"property": "voltage",
"type": "numeric",
"unit": "mV"
},
{
"access": 1,
"description": "Measured illuminance in lux",
"name": "illuminance_lux",
"property": "illuminance",
"type": "numeric",
"unit": "lx"
},
{
"access": 1,
"description": "Measured illuminance in lux",
"name": "illuminance",
"property": "illuminance",
"type": "numeric",
"unit": "lx"
},
{
"access": 1,
"description": "Link quality (signal strength)",
"name": "linkquality",
"property": "linkquality",
"type": "numeric",
"unit": "lqi",
"value_max": 255,
"value_min": 0
}
],
"model": "RTCGQ11LM",
"options": [
{
"access": 2,
"description": "Time in seconds after which occupancy is cleared after detecting it (default 90 seconds).",
"name": "occupancy_timeout",
"property": "occupancy_timeout",
"type": "numeric",
"value_min": 0
},
{
"access": 2,
"description": "Sends a message the last time occupancy was detected. When setting this for example to [10, 60] a {\"no_occupancy_since\": 10} will be send after 10 seconds and a {\"no_occupancy_since\": 60} after 60 seconds.",
"item_type": "number",
"name": "no_occupancy_since",
"property": "no_occupancy_since",
"type": "list"
},
{
"access": 2,
"description": "Number of digits after decimal point for illuminance, takes into effect on next report of device.",
"name": "illuminance_precision",
"property": "illuminance_precision",
"type": "numeric",
"value_max": 3,
"value_min": 0
},
{
"access": 2,
"description": "Calibrates the illuminance value (percentual offset), takes into effect on next report of device.",
"name": "illuminance_calibration",
"property": "illuminance_calibration",
"type": "numeric"
},
{
"access": 2,
"description": "Number of digits after decimal point for illuminance_lux, takes into effect on next report of device.",
"name": "illuminance_lux_precision",
"property": "illuminance_lux_precision",
"type": "numeric",
"value_max": 3,
"value_min": 0
},
{
"access": 2,
"description": "Calibrates the illuminance_lux value (percentual offset), takes into effect on next report of device.",
"name": "illuminance_lux_calibration",
"property": "illuminance_lux_calibration",
"type": "numeric"
},
{
"access": 2,
"description": "Number of digits after decimal point for temperature, takes into effect on next report of device.",
"name": "temperature_precision",
"property": "temperature_precision",
"type": "numeric",
"value_max": 3,
"value_min": 0
},
{
"access": 2,
"description": "Calibrates the temperature value (absolute offset), takes into effect on next report of device.",
"name": "temperature_calibration",
"property": "temperature_calibration",
"type": "numeric"
}
],
"supports_ota": false,
"vendor": "Xiaomi"
},
"endpoints": {
"1": {
"bindings": [],
"clusters": {
"input": [
"genBasic",
"65535",
"msOccupancySensing",
"msIlluminanceMeasurement",
"ssIasZone",
"genPowerCfg",
"genIdentify"
],
"output": [
"genBasic",
"genOta"
]
},
"configured_reportings": [],
"scenes": []
}
},
"friendly_name": "motion_sensor_office",
"ieee_address": "0x00158d0007755b21",
"interview_completed": true,
"interviewing": false,
"manufacturer": "LUMI",
"model_id": "lumi.sensor_motion.aq2",
"network_address": 52233,
"power_source": "Battery",
"supported": true,
"type": "EndDevice"
}
]
que le capteur « RTCGQ11LM » expose les propriétés suivantes :
{
"access": 1,
"description": "Measured illuminance in lux",
"name": "illuminance_lux",
"property": "illuminance",
"type": "numeric",
"unit": "lx"
},
{
"access": 1,
"description": "Measured illuminance in lux",
"name": "illuminance",
"property": "illuminance",
"type": "numeric",
"unit": "lx"
},
contrairement au model « ZSS-ZK-THL » par exemple qui lui expose bien :
{
"access": 1,
"description": "Raw measured illuminance",
"label": "Illuminance",
"name": "illuminance",
"property": "illuminance",
"type": "numeric"
},
{
"access": 1,
"description": "Measured illuminance in lux",
"label": "Illuminance (lux)",
"name": "illuminance_lux",
"property": "illuminance_lux",
"type": "numeric",
"unit": "lx"
},
Il y a donc un souci côté Zigbee2mqtt car on a bien un ‹ name › et un ‹ label › différent mais les ‹ property › et ‹ description › eux sont identique. Et si je ne dis pas de bêtise, on utilise le 'property pour faire les ‹ external_id › et ‹ selector › . Et je ne vois pas trop comment traiter ce cas (sauf à faire une exception dans notre code).
Notre code avec la ligne cause du problème lorsque Zigbee2mqtt fait une erreur à ce niveau (je pense) dans le fichier server/services/zigbee2mqtt/utils/features/completeFeature.js :
Et on voit en dessous que le « name » est également tiré de l’exposes ‹ property › d’où le fait qu’on est 2 fois une feature nommée « Illuminance ».
Malheureusement @Psoy il faudrait faire une issue côté Zigbee2mqtt pour ce device. En attendant y a peut-être moyen de te l’ajouter en mode bidouille si tu veux. Mais je ne sais pas ce que donnerons les maj de datas
Un oubli de leur part ?
Mais j’ai ce capteur depuis plusieurs mois et il a toujours fonctionné, mais comme dit l’autre « ça c’etait avant ». 
Oui, l’impact doit surement venir de l’ajout de l’illuminance_lux ou l’illuminance tout court sur Gladys. Avant l’expose n’était pas traité donc pas de soucis (enfin je suppute toujours hein) !! Du coup ce serait (conditionnel ^^) l’ajout d’une fonctionnalité pour d’autres capteur qui t’a posé problème 
Merci @Terdious d’avoir trouvé celle-là, elle était pas évidente Il me semble qu’on ne peut rien faire de simple côté Gladys mais je vais proposer quelque chose côté Zigbee2mqtt
3 « J'aime »
Merci @cicoub13 
Si jamais chez Zigbee2mqtt ça n’aboutit pas, on pourra toujours rajouter un cas particulier côté Gladys. C’est pas sexy mais parfois dans les cas comme ça il vaut mieux une solution pas sexy mais qui marche
2 « J'aime »