Sans log et autre info concrète la situation risque pas de changée toute seule 
Il faut que je remonte le problème chez Nuki, je pense qu’ils ont provoqué un bug, je note le meme soucis en attaquant directement les APIs par moi même.
C’est pour ca que je ne vous embête pas sur ce message en attendant d’en savoir plus
Et t’as une valeur qui remonte ou pas? Même si c’est pas la même qu’avant/pour les autres modèles (probablement car pas le même firmware)
Voilà ce que j’observe
http://192.168.1.62:8080/lockState?token=XXX&nukiId=YYY
Quand ca marche …
porte fermée et verrou verrouillé
{
"mode": 2,
"state": 1,
"stateName": "locked",
"batteryCritical": false,
"batteryCharging": false,
"batteryChargeState": 82,
"keypadBatteryCritical": false,
"doorsensorState": 2,
"doorsensorStateName": "door closed",
"success": true
}
et porte ouverte donc verrou ouvert:
{
"mode": 2,
"state": 3,
"stateName": "unlocked",
"batteryCritical": false,
"batteryCharging": false,
"batteryChargeState": 82,
"keypadBatteryCritical": false,
"doorsensorState": 3,
"doorsensorStateName": "door opened",
"success": true
}
Puis par exemple je claque la porte
Mais si je fais sur mon Bruno : http://192.168.1.62:8080/lockState?token=XXX&nukiId=YYY
{
"mode": 2,
"state": 3,
"stateName": "unlocked",
"batteryCritical": false,
"batteryCharging": false,
"batteryChargeState": 82,
"keypadBatteryCritical": false,
"doorsensorState": 2,
"doorsensorStateName": "door closed",
"success": true
}
Ce qui me reste à analyser c’est si la callback url est ou n’est pas appelée … ca c’est le scénario quand ca marche « le mieux ». Tot ou tard en forcant un rafraichissement, comme le pont à la valeur, tout rentre dans l’ordre.
Ce que je n’arrive pas à reproduire facilement, c’est quand le pont n’a pas la valeur.
Mais je réfléchis effectivement à me passer du pont et à passer en mqtt, en espérant qu’il n’y ait pas le meme soucis. Meme si je ne pense pas !
Petit bémol pour moi lors des ouvertures/fermetures manuelles* en tournant la bague:
L’état du verrouillage n’est pas mis à jour sur la serrure tant que la bague n’est pas tournée jusqu’en butée.
En position déverrouillée, la partie supérieure du cercle lumineux clignote et permet en quelques secondes de voir si la porte est verrouillée ou non.
Ca a donné une porte restée non verrouillée toute une nuit parce que la serrure avait été ouverte
manuellement.
J’attendais mieux de cette serrure:
- Fabrication tout plastoc
- Verrouillage de porte ouverte malgré le capteur Nuki
- Et la dernière nouveauté: L’état du verrouillage non fiable.
* car plus rapide et silencieux que par le moteur.
L’état du verrouillage n’est pas mis à jour sur la serrure tant que la bague n’est pas tournée jusqu’en butée.
Alors je n’ai pas du tout ce retour, il y a certes une zone morte au niveau de la bascule de la clé, mais si tu t’en éloignes un peu, l’état est correct. Par contre effectivement en ouvrant ou en fermant, il faut dépasser ce point mort si tu tournes à la main, c’est une habitude à prendre.
1 « J'aime »
Je rectifie mon post et j’affine les manipulations sur la serrure:
Ce n’est pas jusqu’en butée qu’il faut tourner la bague. Il faut que le voyant s’allume après verrouillage/déverrouillage physique pour que l’état de la serrure soit à jour.
Bizarre que je ne l’ai remarqué qu’après MAJ du firmware en 4.5.4 
Faute de trouver d’ou ça vient, j’ai fait la bascule vers MQTT hier soir.
Ca faisait un moment que je retardais ça, surtout pour privilégier du full thread/matter avec une 4 pro et une ultra, et plus de 3 pro, mais je verrai plus tard.
Le truc qui m’a sauvé c’est d’avoir à l’époque fait des virtuels, je n’ai eu aucun impact dans jeedom, dans les scénarios, mais aussi dans jeedom connect.
Ca m’a pris une petite heure à tout mettre en place et retester, évidemment ça fonctionne, même si j’ai quelques râtées de remontée parfois.
Par contre j’ai redécouvert que c’est exclusif, c’est MQTT+Wi-Fi ou HTTP-API via bridge, et donc je ne peux plus chercher d’ou vient mon problème de remontée d’ouverture de porte, sauf à revenir en arrière.
Bon, tu as dis que c’était trop tard mais un retour quand même:
- toutes les infos dans les json que tu as fourni sont correctes =>
doorsensorStatevaut 2 si porte fermée et 3 si porte ouverte (comme je dis depuis le début et comme j’ai noté dans la doc); à ne pas confondre avec l’état du verrou qui vaut 1 si verrouillé et 3 si pas verrouillé - sur ta capture d’équipement, je ne vois pas la commande « Etat porte » (numérique) qui doit correspondre à ce
doorsensorState; elle s’y trouvait ou pas?
pour ma part je suis en MQTT+Matter over Thread ! ça consomme beaucoup moins de batterie, je te le conseille, au final c’est le routeur thread (homepod mini) qui se retrouve avec une seconde ip et ça permet à la serrure de parler sur le réseau 
c’est joli. Et fonctionne sur jeedom puisque au final, c’est que du MQTT
1 « J'aime »
oui, c’est ce que j’ai essayé de dire, j’ai montré une séquence « qui marche » en terme d’appels, mais Jeedom n’a pas sa commande de porte ouverte à jour (dans le plugin Nuki, pour la v4 pro, la valeur reste à 3.
Les deux commandes binaires et numériques etaient porteuses des valeurs, mais pas des bonnes valeurs, fermée.
Malheureusement la v3 pro ne le permet pas, c’est Wi-Fi simple, c’est ce qui m’embête, ca va me plomber l’autonomie.
Et je ne parle pas de la v2 pour laquelle ce n’est meme pas une option le Wi-Fi.
voilà, c’est configuré, en fait ça prend deux secondes vu que MQTT est maintenant configuré et qu’elle était déjà sur mon réseau Thread.
On verra à l’usage, à part l’autonomie ça ne doit pas changer grand chose, c’est toujours ça de pris !
Pour la beauté de la technologie
Ah ça c’est sûr, je suis convaincu par Thread et Matter!