Buttons & lights & relays providers refactoring #2414
Conversation
- add light 'custom provider' - autoconfigure stuff with the same methods - drop broker support in favour of custom provider - lowercase ns - global dp filter (todo something better?)
|
FYI, after more testing a transition setting of 2000/100ms hasn't always turned the light OFF after a cold boot. 2000/200ms seems to be OK. Its not as smooth but seems more reliable. |
|
Any logs? |
|
I have |
|
Settings are case-sensitive, so the first key is selected. |
|
For some reason, all webUI debug commands give an error saying "Command not found". I've tried a warm and cold reboot and it still doesn't work. I'll try re loading the .bin |
|
OFF TOPIC - the version and commit version shown top left of the webUI are now merged e.g I had to load a previous build, 1.15.0-dev (2b2fb4f) |
|
What is the message log on boot though? No need to change transition time atm. |
|
Built using standard TUYA environment settings with latest commit. Seems to be working again after deleting that key! |
|
In case its important, the version I was running where I lost access to terminal commands was built using: Also, the NTP server setting has been deleted in the eeprom by defining the |
This looks like a separate issue with the DHCP packets coming from the router running the DHCP server or the way those are parsed, it should contain some valid data and not |
|
1.15.0-dev.git660493a1 I'm still having issues with DEBUG commands in the webUI when building with the settings below. Commenting out the NTP stuff doesn't make any difference. |
|
|
|
FIXED! |
|
Except I've lost LED from the webUI and the green LED has stopped coming ON. 😂 |
|
Just looked and 1.15.0-devacf29958, standard tuya build has also lost LED. Only |
|
Discovery never gets to run in the latest build when config is present. Unless manually set, both btnGPIO0 (0) and ledGPIO0 (14) won't show up |
|
I was just trying that, yep adding those keys has returned the LED to webUI and GREEN LED is working again. |
|
The button thing is another issue I was going to mention. I have only recently noticed, the physical button turns the device ON/OFF but only to 100% and doesn't show the correct state in the webUI. It brings ON the RED LED only. I guess its bypassing the ESP and controlling the MCU directly? I was trying to get the BUTTON_ACTION to dim UP/DOWN with double and long press, but that doesn't work from build definitions. |
|
After doing the factory reset on this device I had to re run: |
|
Debug data when pressing the button from an OFF state, the light then now turns ON at a dim level (webUI shows 102) and then pressing again which returns to OFF. The RED LED goes ON/OFF but the GREEN doesn't. |
|
I am using exact same generic tasmota inline dimmer device that davebuk has (at least the one pictured in #1729) I flashed the latest commit of espurna onto it (this is literally my first attempt ever at flashing this particular device). Without "debug_serial_support" set to zero, I got one slider and one switch, and it did not work. After disabling debug serial support, I now get two switches and two sliders, one slider is called "channel #0" and one is called "brightness", and between these two switches and two sliders, they all seem to affect the state of the dimmer, but in a really random way. I cant even really describe it. Sometimes the either switch might work to either turn the output fully on, or fully off, but sometimes they also dont do anything. Depending on the switches state, either slider might be controlling the actual brightness while the other one has no effect, or vice versa. after playing with one control or the other, the effect other controls have seems to change like a game of whack-a-mole. I figure theres gotta be a bug here somewhere, let me know if I can help somehow |
|
@mcspr Is the expert but I can say what I've done. I believe the TUYA code makes an output/relay using some code from a discovery routine. I have then had to use the following commands in the webUI DEBUG console one at a time. |
|
Oh true. I did manage to put them into the console per your previous message but I never saved or rebooted. duh! Ill try this tonight. Thank you! |
|
I can report back that your instructions worked (After doing a "factory reset"), I see the one button and 2 sliders as you said. I also have noticed that changing the slider from a high value to any value to 0 - 16 results in no change until a value greater than 16 is selected. So for example if the power is 100 and you click on "9" on the slider, the power will still be 100. I think I saw a change recently that ignores values 0-16, but I think it would be good to set the value to 16 still, so its still close to what the slider says instead of up to 84 points off. Ok well let it be known that I have this hardware and am running the latest code on it and anyone can message me if they need me to try something out. |
|
I don't think I tried values that low since the original testing when the device was first added to the code base. It could be worth you making sure that after a cold boot, mains power OFF/ON, the output ends up at OFF. You may see the output flick ON then OFF but it should end up after boot to OFF. You could also try turning transitions ON under the lights menu. I'm currently running 1600ms time with 100ms steps. With transitions working try a soft and cold reboot and check the output ends up at OFF again. |
fwiw transitions actually help with the case since they do channel changes step-by-step instead of an immediate jump to the value. Line 150 in 1b4e515 but this part may be changed to replace the value to 16 instead of just returning I'd open a new issue though, github pagination is the worst and this discussion relates to the already-merged code, not the code in the PR |
total transition time / step time == number of steps, we need to figure out a correct time that serial comms could handle)resolve #2222