Wifi module issue.

[KiwiHC16]

https://github.com/KiwiHC16/Abeille/issues/282

[doudz]

J'ai aussi noté de nombreux problème avec le module wifi, j'ignore pour le moment si le souci vient de ma bibliothèque ou du module wifi. À la réception je vérifie la longueur et le checksum et j'ai très régulièrement des erreurs. J'ai l'impression que le module wifi perd des données dès que les échanges se croisent , ce qui est mon cas puisque je travaille en multithread.

[doudz]

Pour ma part, je pense réécrire le firmware wifi en micropython, (je suis pas très à l'aise en Arduino)

[doudz]

Looking to the firmware code, I saw that it use SoftwareSerial, maybe it's a timing issue when the module spend time to talk over wifi some serial data are lost or corrupt

[KiwiHC16]

Request to bulb to get it's name: echo -ne '\x01\x02\x11\x02\x10\x02\x10\x02\x1e\xd5\x02\x12\x69\xb5\x02\x11\x02\x11\x02\x10\x02\x10\x02\x10\x02\x10\x02\x10\x02\x10\x02\x11\x02\x10\x02\x15\x03' > /tmp/zigate

And socat for transfer: socat -d pty,rawer,link=/tmp/zigate tcp:192.168.4.8:9999

Result:

Feedback from Zigate is nearly always different !

[doudz]

maybe flush() should be remove from code and yield() may be added like this : https://github.com/plerup/espsoftwareserial/blob/master/examples/swsertest/swsertest.ino

maybe related to https://github.com/esp8266/Arduino/issues/1426

[KiwiHC16]

Yep, I saw flush() and used in the past yield. I managed to compile the soft now trying to flash it, but I'm not managing. Don't know why ;-( Sent a mail to akila to get guidance.

[KiwiHC16]

I just managed to do it through the air. Investigations to continue...

[doudz]

Could you share your code here ?

[KiwiHC16]

https://github.com/fairecasoimeme/ZiGate/tree/master/Module%20WiFi/Firmware No change yet. If I do I'll propose it on Akila's github.

[doudz]

oh ok, I supposed that you made change

[KiwiHC16]

Even with yield() everywhere I still have the issue. If I log what is read on the serial coming from zigate, I can see the mistake. So issue is on serial to zigate. Source of the code at https://github.com/plerup/espsoftwareserial Stating: "Please note that due to the fact that the ESP always have other activities ongoing, there will be some inexactness in interrupt timings. This may lead to bit errors when having heavy data traffic in high baud rates." Even if we are not in eavy traffic I think we should try with lower speed. I did the same test on a standalone ESP8266 and I have the same issue.

[KiwiHC16]

Conclusion tonight: don't use softserial but HW serial.

[doudz]

Esp has Hardware uart but I suppose it is used by the USB plug to flash the firmware

[KiwiHC16]

Yes. So why not to use it in prod. No CRC error this morning after 7h.

[doudz]

But it require a new wiring since hw uart is on different PIN

[KiwiHC16]

Exact.

If you don't want to touch the HW, reduce the speed of the link (Should work). Need to recompile Zigate with reduced link speed but is not so easy, I tried yesterday and some lib are not happy with lower speed.

HW, cut the track of GPIO 12/14 and connect Zigate connector to TX/RX.

Or do like me: https://github.com/KiwiHC16/Abeille/blob/master/Documentation/950_Wifi_Module.adoc

Jeedom/Abeille works like a charm with this solution.

[doudz]

lol nice hack Well, @fairecasoimeme should stop selling the wifi module since it's almost unsuable maybe the firmware could be improve to give more priority to software serial, it will be not perfect but can save people having this revision of the wifi module

@fairecasoimeme in the next board revision maybe you can add a switch to redirect tx/rx to zigate or to USB

[doudz]

Did you try to change the buffer size? Currently it's 128 ,maybe we could try 256 or 64 to see if something change ?

[KiwiHC16]

Yes. This is not a buffer issue because even with very short messages the problem exist. It's not a problem of // messages (Up/Down at the same time).

[KiwiHC16]

It's probably a lib issue. Now the challenge is to find the right piece of SW...

[doudz]

Or reduce zigate baudrate

[KiwiHC16]

Akila has some ideas. Let see the results of his tests.

[pdecat]

Same issue here, ZiGate Wifi module is really unstable right now (bad checksums and no response errors, then stops responding to ping until power cycled).

[pipiche38]

I would like to report something that I discovered during the weekend with a user of the Domoticz/Zigate plugin. It looks like if you flow 5 zigate command in the same second, the Zigate module is loosing nearly all except the 1st one .

Shall not the TCP stack to manage the communication ?

[KiwiHC16]

Which TCP Stack ? (Are you in Wifi or USB ?)

[pipiche38]

Wifi ..

[KiwiHC16]

TCP is between App/Plugin and WiFi module. It doesn't know about ZiGate. It doesn't how long the ZiGate will take to find the equipment (could be few second based on my experience). Up to the app to control the flow. SQN number send back by ZiGate is a start...

[pipiche38]

Why is that to the App level to manage communication flow , this is exactly what is done from App <-> Plugin <-> Wifi

Wifi <-> Zigate should control the flow.

Even on Serial communication you have RTS / CTS

[KiwiHC16]

Even on Serial communication you have RTS / CTS

In my short experience I have never seen it used. Never seen it used with Zigate neither. If you have opposite information, please share.

Why

Because if you check all protocol stack from your APP to the Equipment, you will see that many ctrl are not in place.

[pipiche38]

Bonsoir,

Je confirme l'augmentation du nimbres de CRCs avec le nombres de Devices. Pour moi il y a plusieurs problèmes 1- le flow entre le module zigate et le module wifi doit être contrôlé. Je suppose que les débits et durée de traitements ne sont pas égaux et donc on ne peut faire l’hypothèse que ça se passe bien. 2- le Wifi 2.4 et le ZigBee sont sur la même bande 2.4 Ghz, par conséquent chaque module passe du temps sur des messages qui ne lui sont pas destinés. Donc je me pose la question sur Wifi et Zigate. 3- Quand j'utilise le Network Management pour scanner les channels et voir le niveau d’interférences, les niveaux sur tous les channels sont relativement haut ( > 170 ) 4- aujourdh'ui c'est acceptable avec quelques devices, mais quand on va atteindre les niveaux bien suppérieurs meme le fait de répéter les commandes n'aidera pas, car on saturera encore plus le traffic et de plus les messages async des devices aucun moyen de les faire re-emettre.

Bref, il faut absolument une gestion de flux aussi bien entre Wifi/Zigate que USB-TTL/Zigate

[KiwiHC16]

1) Mon experience, ce n'est pas nécessaire, mais pourrait être mieux. 2) Wifi et Zigbee sur 2.4GHz sur la meme bande: Oui mais pas forcement sur la meme bande, faire une config ou les canaux ne se chevauchent pas. Par défaut 11, 15, 20 ou 25 sur la zigate en fonction du bruit et Wifi en fonction de votre AP Wifi. Canaux wifi et canaux zigbee ne correspondent pas un pour un, voir les plages de fréquence. 3) Dans ce cas, il faut augmenter les ratio signal sur bruit, donc changes mes fréquences, rapproche les équipements les eux des autres,... 4) On est loin de saturé le debit zigbee avec quelques messages par heures. D'après mes stats avec 40+ equipements , j'étais à 1kb/s on a de la marge. Je ne partage que partiellement ta conclusion car de toute façon nous ne pouvons faire de la QoS bout en bout qu'en les équipements finaux ne le font pas et qu'on ne peut changer leur soft. Tout le modèle est en best effort avec aucune garanti de service. Peut être que je me trompe....

Perso je n'ai pas de problème CRC. Peux tu partager la configuration que tu utilises ? Wifi HW 1.3 ? SW 1.3 ?

[pipiche38]

Salut, d'accord avec toi sur la bande passante du 2.4, le problème n'est pas là, il est sur la zigate elle meme.

Zigate Wifi V1.3 avec module Zigate en 3.0e (+ patch spécial pour gérer des 24bits par le biais d'un cast en 32bits)

Quand au chevauchement effectivement je ne suis pas sur les memes cannaux

Wifi sur cannal 11 et Zigate sur cannal 11 (a priroi chois automatiquement par Zigate puisque le channel est à 0 ).

EDITED: Quelques stats (produitent par le plugin Zigate de Domoticz)

Sent:
    TX commands     : 1311
    TX failed              : 0 (0.0%)
    TX timeout          : 38 (2.9%)
    TX data timeout   : 1 (0.08%)
    TX reTransmit       : 0 (0.0%)
 Received:
    RX frame            : 9512
    RX crc errors      : 213 (2.24%)
    RX lentgh errors  : 206 (2.17%)
    RX clusters         : 8191
    RX clusters KO     : 0
Operating time      : 21 Hours 1270 Mins 0 Secs

[KiwiHC16]

Je ne connais pas comment le plug in de doubz fonctionne donc je ne peux t'aider sur ces stats. Perso avec ma sauce, j'ai 0% CRC avec 40+ équipements sur mon réseau.

[jalme]

Hi all,

I have also serious wifi connection issues. Only with 4 sensors and wifi is very unreliable. Running wifi v1.3 and 3.0e.

My home router accepts wifi on 2.4 and 5 GHz so most equipments except ZiGate will connect on 5GHz.

Nevertheless ZiGates network quality deteriorates often (several times a day) and even drops out of the wifi network.

Simple ICMP test during a couple of minutes: 449 packets transmitted, 16 received, +149 errors, 96% packet loss, time 458243ms rtt min/avg/max/mdev = 5.766/130.019/249.699/83.171 ms, pipe 4

Any hint on what to do to improve this?

[pipiche38]

You might have a look to that: https://www.nxp.com/docs/en/application-note/JN-AN-1079.pdf

[jalme]

You might have a look to that: https://www.nxp.com/docs/en/application-note/JN-AN-1079.pdf

Thanks but Zigate is running on channel 11 and my wifi on channel 1 so if I understood the doc this should avoid the type of random quality drops

[pipiche38]

Indeed, you should push your wifi to 13 Channel ; or move the Zigbee channel to 24. What the paper is also recommended is to use the non-overallping channels and in Europe the best channels would be 15,16,21,22; so in your cas if you want to stay on Wifi 1 the best would 21 or 22 for Zigate

On 20 Dec 2018, at 23:40, João Pedro Almeida notifications@github.com wrote:

You might have a look to that: https://www.nxp.com/docs/en/application-note/JN-AN-1079.pdf https://www.nxp.com/docs/en/application-note/JN-AN-1079.pdf Thanks but Zigate is running on channel 11 and my wifi on channel 1 so if I understood the doc this should avoid the type of random quality drops

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/fairecasoimeme/ZiGate/issues/45#issuecomment-449158905, or mute the thread https://github.com/notifications/unsubscribe-auth/AH6FWkqpmTy7qvS2HTKMQqGg-OQy0-w4ks5u7BHYgaJpZM4Uu7j4.

[pipiche38]

solved with Wifi firmware 2.0. Please open a new issue if you still have a problem