search

btsimonh / Tasmota

Alternative firmware for ESP8266 with easy configuration using webUI, OTA updates, automation using timers or rules, expandability and entirely local control over MQTT, HTTP, Serial or KNX. Full documentation at
https://tasmota.github.io/docs
GNU General Public License v3.0
6 stars 3 forks source link

Testing? #10

Closed digiblur closed 2 years ago

digiblur commented 2 years ago

Saw your message about testing on the other project? Explain what is needed and such. My discord might be a little better spot to round up some testing. https://discord.digiblur.com should redirect to the invite.

btsimonh commented 2 years ago

yep, already on the discord. So basically, I was having some big issues with touch switches & tas. I think it's that TAS does not respect the initialisation, and the MCUs (or at least mine) can have an issue when sent messages unexepectedly. So.. I've reworked TAS tuya to be a little more formal, especially at startup. But... for a while I can't test with real devices. I get the impression that you probably have a stock :). Certainly I can't test with more than the one device I have...

so.. if you get a chance, check over the commits here, and let me know what you think. It builds and runs on an ESP32 against a tuya simulator (Node-red). Would be great if you have some different devices to test against - always embarassing when I break something ni a TAS PR....

digiblur commented 2 years ago

I will check it out and see what's up but not sure what I am looking for as the few Tuya mcu based devices I have seem to work. I was mentioning discord as others could test some bins for you on various other devices.

btsimonh commented 2 years ago

I'll try to test myself next week on my real devices, then pipe up on discord... can't until then as the WAF factor dropped to zero every time i had to turn ALL the lights off because the units had stopped working with stock TAS! At the moment, I've set them to serial not tuya, and they have not crashed the MCU since ....

digiblur commented 2 years ago

Build a regular BIN for folks and put it on the issue/branch folder and I'll point some folks to it to do some testing.

btsimonh commented 2 years ago

just adding some notes here, prior to making a test version.

1/ I get some serial errors - CS errors in returns, e.g.: 08:09:19.416 TYA: Bad CS 0x9D != 0x19 08:09:19.417 TYA: Raw Data: 55AA0383000802020004000003819D 08:10:00.772 TYA: Bad CS 0x9D != 0x1B 08:10:00.773 TYA: Raw Data: 55AA8107000802020004000003819D 08:20:28.422 TYA: Bad CS 0x9D != 0x1D 08:20:28.424 TYA: Raw Data: 55AA8307000802020004000003819D It may seem odd that it's always 9D, but that's just because it's always the same message that was corrupted. I need to triple check my serial processing....

2/ I've found the exact failure on Athom dimmer: if 'Off' is sent whilst the unit is already off, the unit dies. This is why it dies for me only when under MQTT control, not often local control, as 'Toggle' always toggles the state, whereas from MQTT you can send multiple 'OFF' commands.

Proposed solution: Any set of DP will store the new value(s), then 100ms later, request the DPs from the unit in a state where only if they are different, it will then set them to the new values. For each DP, we'll also need a flag to say it needs to be set which is cleared on receipt of the DP value, as setting a DP value (e.g. DIM) will not necessarily respond with the same value, and so would loop otherwise.

On the Athom device, the evidence of 'death' is no response on panel power button, minor response on dim buttons (only if you long press) fixed dim value.

3/ long press on middle button (only 2s) results in continual 55AA0304000006. Suggest we respond with 55AA0304000006 for each time and count them, when we get to 4, go to AP mode? and reset count after none for 10s.

btsimonh commented 2 years ago

@athomtech @athom-tech - please see email to support? I need your help.

btsimonh commented 2 years ago

ok, it's ready for testing. I'll open a new clean issue...