Closed xoseperez closed 6 years ago
Removing milestone: 1.11.0 (automated comment)
Closing issue then :)
Changes released with 1.10.1.
LOL, certainly this use case was completely out of scope... anyway, this is happening because when "Use JSON payload" is enabled messages are being queued and the queue fills the available memory and makes the device crash. I'm adding a max size for the queue to avoid this. When the queue reaches the max size it sends an MQTT message with all the contents and empties the queue. The code it's already in the dev branch. Will be released with 1.10.1.
Original comment by elmicha (Bitbucket: elmicha, GitHub: elmicha):
If I disable "Use JSON payload", it doesn't crash. If I enable "Use JSON payload" (even if MQTT is disabled), it crashes if I change the values too fast.
Here's a shell script that changes the values from 0 to 255 if you call it with -s
:
#!shell
#! /bin/bash
key="apikey=C3424D34B2B10143"
api_url="http://espurna/api"
usage () {
echo "Syntax:
h801.sh -s|--stresstest
h801.sh R|G|B|W1|W2 number
"
exit 1
}
h801_curl () {
data="value=$2"
method="PUT"
case $1 in
W1-colorwheel)
url="$api_url/rgb"
data="value=$2,$2,$2";;
R)
url="$api_url/channel/0";;
G)
url="$api_url/channel/1";;
B)
url="$api_url/channel/2";;
W1)
url="$api_url/channel/3";;
W2)
url="$api_url/channel/4";;
get)
url="${api_url}s?$key"
method="GET"
;;
esac
curl -X "$method" -H "Accept: application/json" --data "$key" "$url" --data "$data"
}
case $1 in
-h|--help)
usage
;;
-s|--stresstest)
shift
for i in {0..255} ; do
h801_curl R $i
done
;;
*)
h801_curl "$@"
;;
esac
Dev branch. It looks like there is an issue with the ESP8266_new_pwm library in some devices. Using TIMER1 makes it only work at 0% or 100% duty cycles on an Arilux LC01, on an H801 works great. Only have this two right now but using NMI at 500Hz frequency seems to be stable for both of them. Currently on dev. Will test it further before release.
I have opened an issue on the pwm library to find out what's going wrong. I think Stefan will know better if there are issues with different timers and other peripherials (https://github.com/StefanBruens/ESP8266_new_pwm/issues/18).
@SirGioVan 1.10.0 is known to be unstable. If 1.10.1 works it will solve your issue.
Original comment by SirGioVan (Bitbucket: SirGioVan, GitHub: SirGioVan):
Hi just upload espurna-1.10.0-huacanxing-h801.bin here is the video when the bug appears it looks unstable https://youtu.be/fAw17oIcr30
saludos desde Mexico
Original comment by mickare (Bitbucket: mickare, GitHub: mickare):
Hey,
i am back and testing on the MagicHome controller. ^^
Here is the log output of the latest commit on the master branch and spamming the color change:
#!log
mickare@*****:~/git/espurna/code$ pio device monitor --port /dev/ttyUSB0 --baud 115200
--- Miniterm on /dev/ttyUSB0 115200,8,N,1 ---
--- Quit: Ctrl+C | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
[WIFI] MODE STA -------------------------------------
[WIFI] SSID **mySSID**
[WIFI] IP 192.168.**.**
[WIFI] MAC 2C:3A:E8:**:**:**
[WIFI] GW 192.168.**.**
[WIFI] DNS 192.168.**.**
[WIFI] MASK 255.255.**.**
[WIFI] HOST ESPURNA_083CDC
[WIFI] ----------------------------------------------
[MQTT] MQTT brokers found: 0
[NTP] Time: 2017-12-05 01:01:26
[WEBSERVER] Request: GET /index.html
[WEBSOCKET] #1 connected, ip: 192.168.**.**, url: /ws
[WEBSOCKET] Requested action: relay
[RELAY] #0 scheduled OFF in 0 ms
[RELAY] #0 set to OFF
[MAIN] System OK
[WEBSOCKET] Requested action: relay
[RELAY] #0 scheduled ON in 0 ms
[RELAY] #0 set to ON
[RELAY] Saving mask: 1
[WEBSOCKET] Requested action: color
[LIGHT] HSV: 357,100,90
[WEBSOCKET] Requested action: color
[LIGHT] HSV: 117,100,90
[WEBSOCKET] Requested action: color
[LIGHT] HSV: 232,100,90
...
[WEBSOCKET] Requested action: color
[LIGHT] HSV: 352,48,61
[WEBSOCKET] Requested action: color
[LIGHT] HSV: 160,68,61
[WEBSOCKET] Requested action: color
[LIGHT] HSV: 208,36,61
[WEBSOCKET] Requested action: color
[LIGHT] HSV: 88,33,61
[WEBSOCKET] Requested action: color
[LIGHT] HSV: 173,42,61
[WEBSOCKET] Requested action: color
[LIGHT] HSV: 243,29,61
[WEBSOCKET] Requested action: color
[LIGHT] HSV: 209,73,61
ets Jan 8 2013,rst cause:4, boot mode:(1,6)
wdt reset
... and the device restarts.
On commit 489d629
At first I thought the ota firmware was broken, but it seems that the device needs one complete power shutdown (physically) to work correctly again. Then after some seconds it will work like intended.
Again I could not reproduce the fast color switch bug. Also nothing was in the log visible that could indicate the bug.
I experience after 4-5 seconds a short burst of color flickering whenI do a fresh boot (physically toggling power switch). Also some more seconds later there can be again a flickering. After the second flickering it does not appear again.
Wow, great work!
It works perfectly and that smooth color transition is sexy. Also it seems that you accidentally resolved a buzzing noise problem I had with my controllers. :D
But to merge it into the master, that flickering may need some attention. It does not bother me, so I will keep running the dev branch on all three MagicHome controller.
Original comment by Kruno M (Bitbucket: Kruu51, GitHub: Unknown):
It happened to me also. I flashed 1.10.0 version. After one day it stopped responding from Domoticz (on/off) only. I tried trough web interface (fixed IP address) and it worked once. After that I cant connect, I dont see it in my router list.
So I restarted it (4 times power unplug and 2-3 sec waiting in between replugging - that way the original firmware is restarted so tryed it and it worked) but, when restarted I see espurna_xxxxx wifi, but password is not default but it is my password. OK I connect to it, but cant access 192.168.4.1 address., page not found. Ping that address and it is there but not able to load.
So I am waiting new espurna to try flashing it with Platformio again, becausa I cant use upgrade.
What does "barely changing colors" mean?
Original comment by Griskevicius (Bitbucket: griskevicius, GitHub: griskevicius):
I have just one H801. So I cannot help you with Magic Home controller. But I am looking to order more H801 controllers, so I could donate one or two of those if it would help you test. Also I am looking to test it more carefully next week. For a few hours ON and so on.
What I meant is that there is no clear action that will trigger the error. After some testing I found a stable configuration decreasing the PWM frequency to 1kHz and using TIMER1 in the PWM library. I have been testing it with the H801 for an hour without issues, stressing it from time to time. Could any of you test it on other devices like the Magix Home, using the dev branch code?
Original comment by Griskevicius (Bitbucket: griskevicius, GitHub: griskevicius):
No no. For the H801 it is very easy to reproduce. It is a matter of time. Just change colors fast ant device hangs up. Or just dim. Sometimes it hangs up after a few seconds, sometimes after several. But it is guaranteed. If you leave it “On”, ir can stay up for 5 or 10 minutes, haven’t tested ir yet for more.
I have seen a hardware watchdog restart in Huacanxing H801 which uses the same PWM module as the MagicHome. It happens under stress but it's hard to reproduce.
Original comment by Griskevicius (Bitbucket: griskevicius, GitHub: griskevicius):
The same thing happens with H801.
I have lent my magic home to my kid's school for a light table :) I hope they will return it soon, until then I can only test it with other devices.
Originally reported by: gimi87 (Bitbucket: gimi87, GitHub: gimi87)
Yes... the newest sources hangs and resets the device after few tries when i randomly pick some color fast. I will try to debug on the another device, but maybe you will be faster.