Prises commandées Sonoff

[keldo]

Bonjour.

Je me demandais si un des membres du groupe avait déjà testé les prises commandées par WiFi de la gamme Sonoff, comme la S20 ou la S26 ?
Ce sont des produits chinois que l'on trouve à moins de 10 euros sur le net, comme beaucoup d'autres, mais la particularité intéressante est qu'ils sont assez facilement reprogrammables ... et qu'il existe un firmware alternatif sur GitHub qui ajoute le support du KNX sur IP :-)

A tester donc ...

[flop]

Jamais tester mais j'aimerais bien avoir plus d'infos si tu test.. :-)

[DaGGeR]

Intéressé aussi pour avoir un retour de l'installation de ces prises...

J'ai un pote qui en a installés, mais en passant par node red. Et ça a l'air fiable.

[keldo]

J'ai une prise S20 et le matériel pour la reprogrammer (adaptateur USB vers série en 3,3volts) , mais il faut trouver du temps pour chipoter ... Pas simple.

Pour les curieux, le firmware alternatif porte le nom de "tasmota", à trouver sur GitHub.

[DaGGeR]

C'est aussi pour cause de manque de temps, que je n'essaie pas!

Malheureusement

[Michael Halbout]

Pareil manque de temps mais tres interresant

Le samedi 8 septembre 2018 14:36:09 UTC+2, keldo a écrit :

[Olivier]

Bonjour a tous,

Voila ca faisait un petit temps que je voulais tester les prises Sonoff et donc je m'en suis commande pour voir ce que cela donne.

Comme on peut le voir sur les forums ils arrivent maintenant avec des firmwares trop recents pour pouvoir remplacer le firmware par un firmware custom OTA. Il faudra donc passer par la case reprogrammation a travers un port serie.

Comme je n'ai pas encore le materiel necessaire cela prendra un peu de temps avant de continuer les tests.

En attendant, s'il existe des electroniciens parmis vous, est-ce qu'il existe une alternative a la soudure d'1 PIN header sur la carte pour pouvoir connecter la carte au port serie sans devoir souder ? des fiches speciales ou n'importe kwa qui pourrait se connecter directement a la carte sans soudure ?

Merci d'avance

[deyv]

Bonjour,

Je suis sur Toulouse, et j'ai le matériel pour faire cela (je l'ai
d'ailleurs déjà fait, sur deux SonOff).

(note: pas encore expérimenté KNX, vois ci-dessous)

Cela prends 5mn, il faut par exemple ce "pin header"
        (femelle)
        https://www.ebay.fr/itm/Barrette-connexion-40-pin-Femelle-Male-2-54-mm-header-ARDUINO-PI-EB01/192487592295
        (ou mâle)
        https://www.ebay.fr/itm/Barrette-de-connexion-40-pin-Male-secable-Header-Arduino-Raspberry-Pi-EB03/192372082508
(il faut souder seulement 4 pins, il y a peu de risque avec n'importe quel fer à souder)

Pour le programmer si vous n'avez pas de matériel:

Un convertisseur usb-série
        https://www.ebay.fr/itm/PL2303HX-USB-to-TTL-RS232-comUART-module-adaptateur-cable-serie-pour-Arduino-r/332757740199
4 cables:
        https://www.ebay.fr/itm/Cables-Dupont-10-20-30-cm-male-femelle-MM-MF-FF-ARDUINO-Raspberry-DIY-F001/192366235260
        (4 cables male-male ou male-femelle selon le "pin header" choisi)

Je ne connais pas d'alternative fiable sans souder.  Pour reflasher une
seule fois sans souder c'est bricolable mais pour pluss de pérénnité c'est
beaucoup mieux avec le "pin header" (d'autant plus qu'on peut ajouter des
capteurs sur ces pins apres la reprogrammation, ou avoir besoin de
reprogrammer par port série).

Etant personnellement très impliqué sur le projet esp8266/arduino, c'est
quand même par le biais de ce fil de discussion que j'ai découvert en
particulier SonOff-Tasmota dont on parle sur ce fil
(https://github.com/arendst/Sonoff-Tasmota ayant le support KNX, qui repose
sur esp8266/arduino).

Je n'ai pas encore fait mes propres tests KNX, mais d'après ce que j'ai
compris, le firmware alternatif "tasmota" du SonOff peut être à la fois
device (comme le relais) ou "commande".

Pour la "commande" et comme tout le monde ici a l'âme de bricoleur, je ne
saurais que vous conseiller de faire l'acquisition d'un esp8266 avec port
série intégré (le meme chip que le sonoff), pour faire des experimentation
KNX sans fer à souder.
Cela ferait une bonne télécommande KNX sans fil :)
par exemple
        https://www.ebay.fr/itm/NodeMCU-Lua-ESP8266-ESP-12-WeMos-D1-Mini-WIFI-Developpement-Board-Module-TE441/153138927309
(c'est moins cher chez aliexpress chez qui je me fournis pour ce matériel).

david

[keldo]

Voici déjà quelques semaines que j'ai pris mon courage à deux mains et le fer à souder dans la troisième pour ajouter une ligne de pinoches sur le port série de ma prise S20. il faut tout démonter et libérer le circuit imprimé pour pouvoir travailler proprement mais cela ne présente pas de difficulté particulière.

Ceci fait, on garde la prise S20 avec les enrailles à l'air et peut maintenant s'attaquer à la reprogrammation.

Attention, TOUTES les étapes se font SANS brancher la prise S20 sur le secteur !  C'est le câble USB-Série qui fourni l’alimentation de la puce à reprogrammer, donc, j'insiste, il ne faut pas brancher la S20 sur le 230V avant que tout ne soit fini !

Coté ordinateur, j'ai utilisé un PC portable avec Windows 7, sur lequel j'ai installé le programme gratuit "Atom" qui est un éditeur de texte "hackable", donc modifiable par ajout de modules, ensuite j'y ai ajouté le module "Patformio IDE". Ce module "Platformio" contient un compilateur et diverses librairies dont celles pour la puce au coeur de la prise S20.

Depuis le site "tasmota" sur GitHub, on peut télécharger un archive contenant tous les fichiers sources, il faut ensuite la décompresser en local sur le PC.

Après avoir redémarré l'éditeur Atom, on peut le faire pointer sur la base des fichiers sources Tasmota et effectuer quelques réglages dans deux fichiers de configuration; personnellement, j'ai laissé un maximum de paramètres par défaut mais j'ai tout de même directement ajouté la configuration pour mon réseau WiFi (SSID, mot de passe WPA2).

Maintenant il faut ajouter un pont USB-Série qui fonctionne en 3,3 volts coté série et peut alimenter la puce avec cette tension, ensuite trouver le port COM virtuel associé sous Windows et ajouter cette information dans un fichier de configuration sous Atom.

Retirer le pont USB-Série du PC et le raccorder coté série sur la prise S20, préparer ses trois mains et rebrancher le pont sur le port USB du PC tout en maintenant le bouton de la prise S20 enfoncé quelques secondes pour mettre la puce en mode programmation. N.B. Ça marche aussi avec seulement deux mains mais c'est moins simple.

Maintenant, on peut lancer une compilation du firmware sur Atom/Platformio, cela prend 2 à 3 minutes et, à la fin de la procédure, si la compilation s'est bien passée, le firmware est automatiquement programmé sur la S20, ce qui prends aussi 2 à 3 minutes.

Chez moi, la programmation s'est planté 2 fois et j'ai donc du effectuer la procédure complète plusieurs fois.

Une fois la programmation réussie, on peut débrancher le pont USB-Série et remonter la prise S20 proprement.

Maitenant, on peut brancher la prise S20 sur le secteur, attendre qu'elle trouve le réseau WiFi, s'authentifie et obtienne une adresse IP --> faut jetter un oeil sur le serveur DHCP / son routeur / sa Box pour connaitre l'adresse IP de la prise S20 (ou alors on lui avait attribué une adresse IP fixe dans les fichiers de configuration).

Si tout a bien fonctionné, le site "http://adresse-ip-de-la-S20" doit vous afficher une page pour gérer la prise S20.

A partir de là, le firmware Tasmota est installé mais, dans mon cas, il s'agissait du firmware de base sans KNX (j'avais essayé de configurer le KNX sur Platformio mais la compilation se plantait ... à creuser), donc j'ai lancé une mise à jour du firmware vers une version KNX disponible en ligne ... quelques minutes d'attente, un reboot de la S20 et, bingo, l'option KNX apparaît dans la partie configuration.

Configurer une adresse physique, quelques adresses de groupe et associer le tout au bouton et au relais de la S20 est assez logique et facile, personellement, j'ai aussi désactivé les autres protocoles de communication dont je ne me sers pas (MTQQ, etc).

Par contre j'ai eu quelques problèmes sous ETS5 pour créer un participant "dummy" car ma prise S20 se trouve forcément sur une ligne KNX de type "IP" et non pas "TP" (= câble vert) ... et je n'ai pas trouvé de fichier .vd5 pour un participant "dummy" sur ligne IP qui soit accepté par ETS5 ... si quelqu'un en a un, cela m'intéresse !

Mais j'ai finalement bidouillé un truc dans ETS pour m'en sortir, ajouté les adresses de groupe utilisées sur ma S20 aussi à d'autres participants sur câble vert et, surtout, bien pensé à reprogrammer mon coupleur de ligne/zone qui fait la passerelle entre câble vert et ethernet/IP pour que ces adresse de groupe soit aussi vues coté ethernet (c'est pour çà que créer un participant "dummy" sur la ligne "IP" est nécessaire ...).

Et là, youpie, çà fonctionne, je peux allumer ou éteindre la lampe derrière ma prise S20 depuis un poussoir KNX et, inversement, quand j'allume ou éteins ma lampe depuis le boton sur la S20, les leds de retour d'état sur mon poussoir KNX sont bien mises à jour.

Super, çà marche !  ... enfin, durant "un certain temps" comme aurait dit Fernand (à propos du fut du canon ...).

Et oui, car après 15-30-45 (?) minutes, je peux pousser comme je veux sur mon poussoir KNX ... rien ne bouge sur la S20, par contre l'inverse (pousser sur le bouton de la S20) fonctionne nickel et réactive le lien dans les deux sens avec le bus KNX pour "un certain temps".

Bref, y'a comme un problème.

Cela fait maintenant un mois que ma S20 est reprogrammée avec le firmware Tasmota KNX déjà compilé et disponible sur le web , c'est à dire compilé avec les paramètres et les librairies par défaut.

Tout fonctionne parfaitement, mis à part le lien KNX qui se perd après un temps variable ... et pour une durée variable, par contre, un appel vers la page web intégrée de la S20 fonctionne toujours.

Ce n'est pas un problème de mauvais signal WiFi et la S20 ne semble pas défectueuse.

Pour moi, le problème est ici :

- Le protocole KNX/IP utilise le "multicast", les messages KNX ne sont donc pas adressés à une adresse MAC spécifique.

- Pour économiser l'énergie, la puce de S20 se met en veille régulièrement et ne se réveille que lors d'une activité externe :

   - un pression sur le bouton de la S20

   - la réception d'un message ethernet/WiFi spécifiquement adressé à son adresse MAC, comme un appel à sa page web par exemple

   - un timer interne

Donc, un télégramme KNX/IP n'étant pas directement adressé vers l'adresse MAC de la prise S20, une fois endormie, la S20 ne se réveille pas !

La solution tient probablement en la modification de certains paramètres avant compilation (désactiver le deep sleep ?, une autre librairie WiFi qui tient aussi compte des messages multicats , ... ?).

Je ne sais pas trop quand, mais compte bien chipoter pour trouver une solution.

Au pire, j'ai un micro serveur Linux qui pourrait envoyer un ping vers la S20 toute les 5 minutes.

En attendant, j'ai commandé 2 autres prises S20, car pour environ 10€ pièce, elles sont plutôt bien conçues et fabriquées ... et c'est mois de un dixième du prix d'une prise commandée KNX RF ou PL ... sans compter qu'il faudrait encore ajouter une passerelle spécifique.

[marc.assin]

Le mardi 18 décembre 2018 12:08:03 UTC+1, keldo a écrit :

Voici déjà quelques semaines que j'ai pris mon courage à deux mains et le fer à souder dans la troisième pour ajouter une ligne de pinoches sur le port série de ma prise S20.

Salut Keldo.

Pas mal ! 

Ce serais bien si tu pouvais poster ton texte sur le site, çà laisse une certaine longévité.

Merci et

A+

[DaGGeR]

Merci pour ce retour !

Je me suis enfin décidé à passer commande. Restera à trouver du temps pour faire la manip, mais si le matériel est là, ...ça aide!

Le mardi 18 décembre 2018 12:08:03 UTC+1, keldo a écrit :

[DaGGeR]

J'ai reçu les prise ce week-end, et comme je n'avais pas grand chose de prévu, je me suis décidé à faire la manip directement.

- Soudage facile des 4 pins pour la programmation

- Programmation difficile de la Sonoff... Premiers essais avec un PC sous Win10, NOK . Installation sur un PC sous Win7 OK . Et problème d'inversion TX et RX où j'ai mis du temps à comprendre pourquoi.

- Après flashage, configuration de l'adresse physique et des adresses de groupe

- Malgré l'envoie du status du relai ( KNX: Output 1 = 1 sent to 1.5.1 ) sur le groupe 1/5/1 configuré dans ETS je ne reçoit rien dans ETS et le moniteur de groupe.

- Pareil si je commande le relai via la visu , rien ne se passe

Je sèche !

[DaGGeR]

Je pense avoir trouvé une piste que j'essaierai ce soir.

... L'adresse IP de la gateway que je n'ai pas modifié dans le fichié "esp-knx-ip"

[Olivier]

De ce que j'ai pu rapidement lire du code du knx Tamosa il utiise le multicast -> il ne faut pas configurer l'addresse d'une interface KNX mais avoir un router KNX qui va faire le lien entre le LAN et le reseau KNX. Si pas de routeur knx mais une simple interface, l'utilisation du daemon knxd permet de mettre en place un routeur knx qui se connectera avec l'interface.

C'est quoi ton modele d'interface IP ?

[DaGGeR]

J'ai une passerelle N148/22  ...

Ah zut, je n'avais pas vu ce 'détail' .

Pourtant, tasmota est basé sur la librairie XKNX, et sur XKNX on voit :  "provides support for KNX/IP routing and tunneling devices."

[Olivier]

Meme s'ils s'en sont inspire c'est quand meme different: XKNX c'est une librairie python et Tasmota c'est du C++. Dans le code Tasmota n'ai vu de reference qu'a du multicast mais je n'ai pas tout lu...

[david gauchard]

Tasmota utilise cette librairie arduino/c++:

https://github.com/envy/esp-knx-ip/

[Olivier]

Oui et encore pas tout a fait car ils ont forke cette librairie et l'on incluse dans leur propre code:

https://github.com/arendst/Sonoff-Tasmota/tree/development/lib/esp-knx-ip-0.5.1

Il semble que les deux codes evoluent separement. Toujours est-il que si l'on regarde le code dans 'esp-knx-ip-send.cpp' on ne voit que des references au routage KNX (multicast) et pas au tunneling.

[DaGGeR]

Bon du coup, c'est moins intéressant :)

[Olivier]

Tu peux installer knxd sur un Linux et l'executer en mode router ca devrait marcher (https://github.com/knxd/knxd)

[DaGGeR]

Je dois pouvoir le faire avec eibd aussi , non ?

Sinon, si c'est trop prise de tête, je passe par node-red . Il y a KNX et Tasmota ...

[DaGGeR]

J'ai activé la fonction Routing sur eibd  ( normalement ). Mais je ne vois toujours rien passer quand je commande manuellement le relai.

/usr/local/bin/eibd --daemon --pid-file /var/run/knx/eibd-server.pid -d -D -T -R -S -i -u --eibaddr=1.1.229 ipt:192.168.1.100

[Olivier]

OK, ca devrait marcher avec eibd aussi... Tes options semblent OK. (-d et --daemon sont redondants).

Moi si j'etais a ta place maintenant j'installerais un sniffer reseau (wireshark) et j'esssayerais de voir s'il y a effectivement des trames KNX qui sont transmises sur le reseau vers l'addresse multicast KNX (224.0.23.12). 

Depuis eibd: quand des messages de groupes sont envoyes sur ton BUS des packets multicast devraient etre envoyes sur le LAN.

Depuis le sonoff.: quand tu appuies sur le bouton il devrait y avoir aussi des packets multicasts.

Maintenant je sais pas si tu te sens a l'aise avec un sniffer reseau pour voir ce qui transite sur ton LAN.

[DaGGeR]

J'ai vu qu'il me manque une manip pour que ça fonctionne, je pense :

sudo route add 224.0.23.12 dev eth0

J'ai lancé wireshark, mais je ne voyais rien passé. Ni de mon server Knxweb, ni de la prise en appuyant. 

Il faut que je creuse. 

[Olivier]

Tu peux aussi essayer de capturer directement sur le systeme ou tourne eibd avec tcpdump

Voici un sample de ce que j'ai capture:on peut voir les paquets multicasts generes par knxd ainsi que des paquets venant d'un autre device

rpibla:~ $ sudo tcpdump -i eth0 host 224.0.23.12

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

16:04:49.179360 IP rpibla.3671 > 224.0.23.12.3671: UDP, length 17

16:04:49.246774 IP rpibla.3671 > 224.0.23.12.3671: UDP, length 17

16:04:51.757028 IP rpibla.3671 > 224.0.23.12.3671: UDP, length 17

16:04:51.822865 IP rpibla.3671 > 224.0.23.12.3671: UDP, length 17

16:04:55.569495 IP 172.31.0.193.3671 > 224.0.23.12.3671: UDP, length 17

16:04:55.650996 IP rpibla.3671 > 224.0.23.12.3671: UDP, length 17

16:04:58.032327 IP rpibla.3671 > 224.0.23.12.3671: UDP, length 17

16:04:58.097486 IP rpibla.3671 > 224.0.23.12.3671: UDP, length 17

16:05:00.658071 IP 172.31.0.193.3671 > 224.0.23.12.3671: UDP, length 17

16:05:00.741623 IP rpibla.3671 > 224.0.23.12.3671: UDP, length 17

16:05:04.041768 IP 172.31.0.193.3671 > 224.0.23.12.3671: UDP, length 17

16:05:04.122973 IP rpibla.3671 > 224.0.23.12.3671: UDP, length 17

^C

12 packets captured

12 packets received by filter

0 packets dropped by kernel

[DaGGeR]

Merci pour la commande :)

Je n'arrivai pas à utiliser Wireshark sur la machine distante en ouvrant un socket.

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

18:02:16.849152 IP Wizzz-PCTV.local.3671 > 224.0.23.12.3671: UDP, length 17

18:02:16.943314 IP Wizzz-PCTV.local.3671 > 224.0.23.12.3671: UDP, length 17

18:02:17.005137 IP Wizzz-PCTV.local.3671 > 224.0.23.12.3671: UDP, length 18

18:02:24.936368 IP Wizzz-PCTV.local.3671 > 224.0.23.12.3671: UDP, length 17

18:02:32.469139 IP Wizzz-PCTV.local.3671 > 224.0.23.12.3671: UDP, length 17

18:02:32.564103 IP Wizzz-PCTV.local.3671 > 224.0.23.12.3671: UDP, length 17

18:02:32.625924 IP Wizzz-PCTV.local.3671 > 224.0.23.12.3671: UDP, length 18

18:02:41.117017 IP Wizzz-PCTV.local.3671 > 224.0.23.12.3671: UDP, length 17

18:02:41.117237 IP Wizzz-PCTV.local.3671 > 224.0.23.12.3671: UDP, length 19

18:02:44.865164 IP Wizzz-PCTV.local.3671 > 224.0.23.12.3671: UDP, length 21

Donc le mode Routing est bien actif.

Mais rien quand ce commute le relai de la Sonoff.

Et je ne vois rien sur Wireshark . J'ai l'impression que rien ne sort du serveur eibd . Pourtant j'ai fait : ip route add 224.0.23.12 dev eth0

Mais il y a cette ligne dans le dump :  ( 192.168.1.250 étant ma passerelle IP )

18:28:51.375648 IP 192.168.1.250 > 224.0.23.12: igmp v2 report 224.0.23.12

[DaGGeR]

Les nouvelles du lundi matin .....

Ça ne marche toujours pas!

J'ai réinstallé un firmware déjà compilé dans la Sonoff pour être sur de ne pas avoir merder.

J'ai modifié des paramètres de configuration de la carte réseau.

Je suis en train de regarder si ça ne vient pas du firewall. Le server est sous Ubuntu 14.04

Sinon, j'ai commencé à regarder si je pouvais installer un Conteneur knxd ou eibd sous Docker ... , pour essayer de comprendre ou est le point de blocage.

[Olivier]

Si j’ai bien compris tu as un Windows avec wireshark et un Ubuntu avec eibd? Tu dois absolument t’assurer que tu as pas de firewall actif sur ces deux machines au moins le temps de debugger et aussi que tu fais tourner wireshark avec les privilèges admin et l’interface ethernet en mode promiscious.

[DaGGeR]

Effectivement, le PC avec Wireshark est sous Win10.

Sous Ubuntu, il y a eibd, linknx ,.... J'ai vérifié, il n'y a pas de firewall sur celui-là. Donc il devrait voir passer les trames venant de la prise Sonoff. 

Dans mon dump, j'ai le nom de mon PC puis .local.3671  ( Wizzz-PCTV.local.3671 ) alors que toi, tu as juste le nom de ton PC.3671 ( rpibla.3671 )

=> Ca ne viendrai pas de là ?

Mais comment changer ?

[Olivier Blaise]

Non ça c’est juste la manière dont le hostname est configuré rien à voir avec le problème. Il suffit d’ailleurs d’ajouter l’option -n pour voir l’addresse IP a la place

--

---
Vous recevez ce message, car vous êtes abonné à un sujet dans le groupe Google Groupes "domotique-EIB".
Pour vous désabonner de ce sujet, visitez le site https://groups.google.com/d/topic/domotique-eib/9R9nt7cGiWg/unsubscribe.
Pour vous désabonner de ce groupe et de tous ses sujets, envoyez un e-mail à l'adresse domotique-ei...@googlegroups.com.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

[DaGGeR]

Bon ... je pense avoir trouvé mon problème !

Ma Box SFR

Pour rappel, je ne reçois aucune trames multicast venant de mon server eibd, sur mon PC portable connecté en wifi. De même, le server eibd ne voit pas les trames venant de la Sonoff.

Après avoir cherché partout, je me dit que le point commun est le WiFi. 

Je connecte donc mon PC portable en câblé, et là miracle, je vois les trames passer. :) . Mais toujours pas celle de la prise Sonoff, normal car resté en WiFi.

Ayant parcouru les paramètres de la Box, il n'y a pour moi aucun paramètres bloquant ce type de trames. Sauf la volonté de SFR de bloquer la diffusion des trames IPTV sur les appareils mobiles.

J'ai une vieille passerelle WiFi, je la connecte dès que possible pour valider mon pb...

[DaGGeR]

Validation !

C'est bien le WiFi SFR qui pose problème 

Fonctionnement OK dès la connexion de la prise sur la passerelle.

Donc Sonoff<>Tasmota<>WiFI<>KNX Ok, mais pas sur SFR   :)

Merci pour toutes les aides reçues, les astuces!

Il me reste maintenant à trouver la solution définitive que je vais mettre en place pour 'doubler' le WiFi

[marc.assin]

Bonjour,

Ce serais bien si qq voudrais prendre la peine de publier son retour d'expérience sur le site

https://sites.google.com/site/domotiqueeib/home

amha, ce genre de setup sera de plus en plus demandé. Perso, c'est déjà dans ma to-do list

marc.assin

[keldo]

Pour ce qui est d'une version au propre sur le site, il faut que je trouve le temps mais c'est aussi sur ma to-do-list.

Mais encore faudrait-il trouver une solution a la perte de connectivité après quelques minutes ... Aussi sur ma to-do-list mais avec une priorité légèrement plus élevée. ;-)

[DaGGeR]

Pour la perte de connectivité, je pense qu'il faut modifier le paramètre 'Sleep' pour le mettre à 0

http://xxx.XXX.xxx.XXX/cm?cmnd=Sleep%200

(Also, if using KNX IP Protocol, sleep needs to be 0 in order to avoid losing any telegram.)

[keldo]

Après vérification je pense que le "sleep" est bien désactivé, j'obtiens ceci comme réponse :
{"Sleep":"0 (0)"}

Testé avec les 3 derniers firmwares et actuellement en version 6.4.1(knx).
Toujours pas résolu ...

[keldo]

Petite correction , d'après les log, ma S20 avait une valeur de 50 pour "sleep" avant que je ne teste la commande, et maintenant la valeur est bien passée à zéro ...
Y a plus qu'à retester durant quelques jours.

[DaGGeR]

Oui, par défaut, la valeur est à 50

La commande que j'ai donnée change la valeur à 0 ( Sleep 0 , traduis en Sleep%200 )

pour connaitre la valeur : http://xxx.XXX.xxx.XXX/cm?cmnd=Sleep

Moi je n'ai pas ce problème de connectivité avec la valeur à 0.

[DaGGeR]

Je viens de mettre en ligne un document sur le modop.  https://sites.google.com/site/domotiqueeib/home/sonoff

Ne pas hésiter à le modifier, faire évoluer, commenter si besoin

Comme je l'ai écris en fin de document, merci à Keldo, Tasmota, et autres infos récupérées !

[keldo]

Retour d'expérience après quelques semaines avec le paramètre sleep=0, la différence est notable mais ce n'est pas totalement parfait, j'ai tout de même encore eu deux pertes de connectivité.

[DaGGeR]

P'tit retour après quelques mois d'utilisation...

Aucun problème de perte de connexion, les prise commutent directement lors de l'appui sur la visu.

Même si je reste plus de 2 semaines sans commuter une des prises

Pour mon problème de Wifi ( qui filtrait les trames KNX ) j'ai mis des antennes Ubiquity LR avec un contrôleur sur Docker ( NAS Synology )

Tout marche à merveille

==> Donc pour moi, très bonne solution pour commander des appareils occasionnellement, ou pour modifier l'installation après coup 

Quelqu'un a t'il tenté l'expérience ?

[Julien Baldini]

Je peux juste te répondre sur les AP ubiquiti

J'en ai depuis quelques temps et je les ai aussi conseillé à pas mal de monde et tout le monde en est enchanté

 

Pour le contrôleur, il y a plusieurs possibilités sachant qu'il n'est indispensable que pour la configuration des AP

Sinon, le controleur est nécessaire si comme moi, tu as configuré un réseau guest, c'est lui qui gère le portail d'accès.

Si ce n'est pas utilisé, on peut lancer l'application à la demande lorsqu'il faut faire un changement de config

 

Plusieurs solutions pour faire tourner le contrôleur

-> Ubiquiti vend un serveur sur une clé rj45, pas besoin de VM ou autre soft sous docker

-> Une VM avec le service installé

-> sous docker

 

Perso, j'ai une VM sous vmWare

 

Bonne journée,

 

Julien

 

--

---
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "domotique-EIB".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse domotique-ei...@googlegroups.com.
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/domotique-eib/acfa3098-30a4-418c-a684-4527e0f75a86%40googlegroups.com.