Lazer

Je l'ai faite le week-end dernier sans aucun souci sur mes 3 modules

Malheureusement c'est comme au Black Friday, peu de produits concernés, et surtout des anciens produits, évidemment pas les produits les plus intéressants.

Ils faisaient mieux certaines années précédentes.

il y a une heure, Cmoi20 a dit :

l'ensemble des modules zigbee apparaissent en erreur

Tu aurais une capture d'écran de ça ?

J'essaie de comprendre... d'autant plus que j'attends mes 4 premiers modules Zigbee... (enfin s'il arrivent un jour, surement l'effet saturation du Black Friday car j'ai aussi un autre colis en souffrance perdu dans la nature...)

Au pire si mes (probablement futurs) modules Zigbee déconnent aussi, je pourrai les utiliser en Wi-Fi.

Mais bon...  vu les retours sur le forum officiel, intuitivement je persiste à penser que c'est bien un bug de la HC3 (dans la DB, dans le code qui gère tout le bouzin, dans le chipset, va savoir...), et c'est complètement indépendant du réseau IP, d'ailleurs pourquoi ça le serait ?
Des interférences radio avec un appareil quelconque, oui c'est toujours possible... bon après on peut aussi accuser le Linky, bien qu'il soit un peu passé de mode ces derniers temps...

Je ne comprend pas trop la discussion actuelle sur le Wi-Fi.

Si j'ai bien compris le problème, c'est que les modules Zigbee disparaissent de la box, c'est bien ça ?
Dans ce cas, l'erreur est dans la DB de la box, ça n'a absolument rien à voir avec l'adresse IP, la connexion Ethernet, le Wi-Fi, ou une quelconque interférence radio avec le Zigbee.

C'est alors bien avec le support Fibaro qu'il faut avancer, seul eux ont la main sur le code interne de la box qui gère (mal) le Zigbee.

Sur le forum officiel, on ne compte plus les messages qui relatent les mêmes problèmes....

Si en revanche les modules Zigbee sont toujours connus, mais que la communication ne passe pas, alors là oui, ça pourrait bien être un problème d'interférence Wi-Fi.
Dans ce cas, il faut aller dans les paramètres des points d'accès Wi-Fi pour désactiver les canaux réservés au Zigbee pour éviter tout interférence.

Même si c'est sans garantie, car les interférence peuvent arriver depuis les réseaux Wi-Fi des voisins... et dans tous les cas, moins de canaux pour le Wi-Fi, c'est se créer des interférences au sein même du réseau Wi-Fi avec les canaux de ses voisins, et in fine une baisse du débit utile.

Ah tu avais fait un transfert direct de box à box ! Oui, il y a surement eu des inconsistances que tu ne découvres que maintenant.

L'information est passée inaperçue dans le changelog, mais cette version apporte quelques modifications sur l'API, 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
    }
})

Le problème du niveau de pile, c'est que ce n'est pas linéaire, le module a beaucoup de mal à estimer le niveau de charge restant avec pour seul indicateur la tension de la pile.
C'est encore plus vrai avec les petits piles, qui ne sont pas de type alcaline, mais au lithium ou autre technologie (et c'est encore pire avec les accus rechargeables).

En effet, la chute de tension n'est pas linéaire, au début la tension reste stable, puis elle chute très vite sur la fin.

Je le vois très bien sur le graph des batteries dans DomoCharts, sur tous mes FGMS, une courbe plate au début, puis qui chute de plus en plus rapidement.

Pour certains, le niveau de batterie estimé peut passer de 30 voire même 40%, à 0% en seulement 2 jours :

Et encore, le FGMS n'est pas le pire, j'ai d'autres types de modules où la chute brutale est encore plus marquée.

C'est malin... mais ça ne fonctionne pas !

J'ai essayé, cette fois-ci c'est le dernier chiffre qui disparait, car il y a un partern de 10 chiffres à respecter, c'est codé dans le code LUA du mon QA JPI.
Le "+" disparait, mais le "33" prend la place du "0" initial, donc le dernier chiffre passe à la trappe.

Il faudrait donc modifier le code LUA du QA

En revanche, en lisant le code, j'ai trouvé un truc qui correspond exactement à ma suggestion d'utiliser une table, en fait c'était déjà implémenté depuis le début, puisque l'idée c'était de pouvoir envoyer un SMS à plusieurs numéros en 1 seule fois.
Il suffit de mettre un seul numéro dans la table, et là ça fonctionne, entre accolades, comme ceci :

hub.call(52, "sendSMS", "Hello World", "", {"0612345678"})

Merci pour ton log détaillé, j'ai pu reproduire chez moi, et j'ai le même comportement, à savoir que dès lors qu'on passe un numéro de téléphone, même sous forme de chaine de caractère avec les guillemets, lors de l'appel de la fonction sendSMS au sein du code LUA du QuickApp JPI, cette fonction reçoit un nombre (number) au lieu d'une "string".

S"agissant d'un nombre, le (ou les) 0 devant la suite de chiffre est considéré comme inutile et donc retiré automatiquement.

Conséquence... mon QuickApp devient inutilisable pour envoyer un SMS à un numéro de téléphone en particulier.

Je suppose que le comportement de l'API a été modifiée par Fibaro entre le moment où j'ai écris ce QuickApp et maintenant... lors d'une mise à jour dont ce changement de comportement n'aurait pas été documenté, comme c'est souvent le cas avec Fibaro.

J'imagine 2 solutions pour contourner le problème, mais aucune des 2 ne me convainc vraiment :

- dans la fonction sendSMS(), détecter si le nombre reçu est une suite de 9 chiffres, auquel cas on le retransforme en chaine de caractère pour y rajouter le 0 manquant.

- modifier complètement la syntaxe de sendSMS(), au lieu de lui envoyer différents arguments (que l'API Fibaro remettra en forme comme bon ça leur chante), passer un tableau (table) avec différents élément, ce qui garantie que chaque paramètre ne verra pas son type changer.

Moyen tout ça.... je me permet de te suggérer à nouveau de ne plus utiliser directement les numéros de téléphone, mais de passer par le nom du destinataire.

Il y a 2 heures, TitiXsi a dit :

Tiens... Je rebondis. Ils ont autorisé un adaptateur USB ethernet ? Pour palier le fait que le port d'originalité est un 100Mb ?

Alors sur la HC 3 Lite c'est possible, car elle n'a que le Wi-Fi de base, et on connait tous la (non)-stabilité du Wi-Fi.

Mais sur la HC3, je ne vois vraiment pas l'intérêt de s'emmerder avec un adaptateur Ethernet USB ? Sachant que le gigabit est inutile pour une box domotique (pas de transfert de fichier, etc).
Le choix d'un port 100 Mbps est tout à fait pertinent de la part de Fibaro, d'une part ça réduit les couts de production, et d'autre part ça réduit la consommation électrique, ce qui est intéressant pour l'utilisateur.

Par ailleurs, ça n'apporte aucune restriction, même sur les switchs récents avec les ports en 2.5, 5, et même 10 Gbps, la vitesse est toujours rétrocompatible avec le 100 Mbps (en tout cas sur les modèles que j'ai vu, UniFi notamment)

Cela te convient peut être, mais perso je trouve que c'est très court 6 à 12 mois.

Avec des piles (pas des accus donc), ça tiens largement plus longtemps, perso je suis autour de 3 ans par Motion Sensor.

Ouaip, surtout à 48€ pièce pendant le Black Friday, c'est un prix plutôt intéressant étant donné la rareté de ce type de produit, surtout depuis la disparition des Greenwave Powernode.

Du coup j'en ai pris 4

Dont 3 qui ont déjà trouvé leur utilisation, ça m'en fera 1 seule d'avance.

Plus qu'à attendre la livraison, ça part depuis la Pologne car j'ai acheté sur le site officiel.

@henri-allauch Ah bah... ce sont exactement les erreurs que j'avais !!! Et qui donc ne disparaitront pas si j'en crois ton expérience 

J'en ai commandé, attend de les recevoir pour les utiliser avec la Home Center 3.

En espérant que l'intégration native Zigbee fonctionne correctement, sinon je ferai un QuickApp qui utilise l'API via le Wi-Fi.

Shelly Power Strip 4 Gen4

Multiprise intelligente compacte certifiée Matter, avec 4 prises contrôlables individuellement, chacune dotée d’un suivi de la consommation d’énergie et d’un indicateur LED multicolore. Contrôlez et surveillez votre éclairage, chauffage ou tout autre appareil connecté, d'où que vous soyez.

Caractéristiques principales :

• Prise supportant jusqu’à 12 A par prise (16 A au total)
• Prises Type F / Schuko
• Certifiée Matter : Connectez des dispositifs de différentes marques en quelques secondes
• Compatible Apple HomeKit : Contrôlez vos dispositifs depuis l’application Apple Home ou Siri
• Mesure de la consommation électrique sur chaque prise
• Indicateur LED multicolore (mode 'Nuit' inclus)
• Mémoire flash de 8 Mo et puce Shelly ESP-Shelly-C68F
• Scripts
• Prise en charge des programmations, scènes et actions locales
• Design compact et léger
• Câble d'alimentation de 150 cm pour un usage pratique et polyvalent
• Grande compatibilité avec les systèmes et applications domotiques, y compris l’application Shelly Smart Control

Protocoles :

• Wi-Fi

• Bluetooth

• ZigBee

• Matter

Page produit :

• https://www.shelly.com/fr/products/shelly-power-strip-4-gen4

Je n'ai pas de problème de piles avec mes détecteurs de mouvement, ça dure assez bien chez moi, plusieurs années sans souci.
Le souci en fait, c'est qu'avec le nombre de détecteurs, statistiquement, ça fait quand même régulièrement des piles à changer (entre les motion sensor et les smoke detector...)

Mais pour la détection de présence, je n'ai toujours pas franchi le pas, il faudrait que je m'y mette d'ailleurs.

Pour le reste, le retard du support des nouveaux protocoles, les mises à jour régulières qui n'apportent rien, etc, je crois que tu as tout dit

Comme je dit toujours, j'ai une box, elle répond à mes besoins... disons à 99%, le 1% restant je fais sans.
Et puis le jour où j'aurai besoin de plus, et surtout où j'aurai beaucoup de temps libre pour migrer (à quand le prochain confinement  ), je passerai sur Home Assistant.

Evaporation instantanée de la piscine

Les Hardware failure que j'ai rencontré, c'est vraiment occasionnel, et vu que c'est le même log que les QuickApps, qui est purgé au bout de X messages, la plupart du temps quand je regarde, je n'en vois aucun.

En tout cas ça me le fait sur 2 de mes 3 Smart Implants, qui ont justement des sondes de température.
Après je ne suis pas sûr que ça soit lié, mais ça y ressemble.

/logs?search=&tag=ZWAVE&type=

Vous l'avez peut être vu passer sur vos box, une mise à jour version 5.3 du firmware des Smart Implant est disponible depuis quelques jours.

Depuis le début, j'ai de temps en temps des messages "Hardware failure" dans le journal d'événement Z-Wave de ma box, je me demande si les correctifs apportés sur la gestion des sondes de température ne vont pas résoudre ce problème, même si en pratique, malgré ces messages, mes sondes ont toujours très bien fonctionné.

Historique du change log complet :

• Smart Implant FGBS-222
  
  5.3
  A correction has been made to the value returned by disconnected DS18B20 sensors after a power failure. The value 0 has been changed to 125.
  Corrections have been made in connection with occasional problems related to the detection of the presence and actual status of DS18B20 sensors.
  
  5.2
  DS18B20 temperature sensor support has been improvements to make it more reliable, especially in long wiring cases.
  Optimized input/output behavior after power reset.
  Other minor improvements.
  Support for version 5.2 devices is available from 4.601 Beta for HC2/HCL.
  
  5.1
  Initial release

Voilà, c'est ça : https://www.frandroid.com/marques/free/2898395_votre-smartphone-est-il-pret-free-mobile-desactive-massivement-son-reseau-3g

Pour le premier, est-ce que ça ne serait pas la pile du détecteur qui faiblit ?

Avec certains de mes Fibaro Motion Sensor, j'ai remarqué qu'il y a parfois des faux positifs quand la pile est en fin de vie (immédiatement corrigé après remplacement de la pile)

Pour la seconde question, ça ressemble à un bug, peut être voir avec le support Fibaro.

Sinon avec l'interface graphique, tu essaye de remettre/supprimer l'association dans l'espoir de nettoyer/resynchroniser les associations pour ce module dans la base de données interne de la box.

Ou bien, tenter une interrogation du module via le bouton dédié.

En dernier recours il reste la reconfiguration du module.

Il faudrait que je fasse des tests, sauf que depuis 5 jours je n'ai plus de passerelle SMS, je viens de comprendre aujourd'hui pourquoi : Free a commencé la désactivation des antennes 3G

Il faut que je vois si mon vieux téléphone est compatible 4G, sinon va falloir que je trouve un autre smartphone encore en état de fonctionnement.

En attendant, est-ce que tu ne peux pas enregistrer le numéro et l'associer à un nom dans la configuration du QuickApp JPI, et ainsi, quand tu appelles la fonction sensSMS(), tu mets directement le nom de l'utilisateur.

Le 0 qui disparait m'a mis sur la piste, car le numéro est traité comme un type "number" et donc le 0 disparait, il est inutile, s'agissant d'un nombre.

Il faut forcer le numéro en mode chaine de caractères, type "string", en ajoutant des guillemets.
Essaye comme ceci :

hub.call(52, "sendSMS", "Dressing libre", "", "0123456789")

Il faut mettre le numéro du contact dans l'argument suivant.

Essaye comme ceci :

hub.call(52, "sendSMS", "Dressing libre", "", 0123456789)

Le QA sera à écrire entièrement, mais tu peux t'inspirer de la documentation Fibaro officielle des nombreux exemples du forum.

Pour la requête HTTP, voir :

Il y a toujours eu des mises à jour du SDK, depuis la HC2... c'est la partie software fournie par le fabricant de la puce Z-Wave.