MQTT Preset does not respect power state

[StefanRu1]

Hi,

i use &PS and &PL to store and reload settings via MQTT. The presets are restored but not the power state the device was in. If i use the Settings in the HTTP UI of WLED the power state is also restored. Is there a reason why this is not working in the MQTT version?

An additional question which came up was, is it harmful to use &PS to often for the ESP rom?

Thanks and best regards, Stefan

[StefanRu1]

Ok, wait i just recognize that it seems to work.

[StefanRu1]

Hmm, thats wired. I have two ESP8266.

For one the PS and PL works fine. For the second one it works not correct.

The second one stores the settings with PS. I can restore them in the WLED HTTP UI. But when i do PL it only restores the color not the brightness.

P.S.: After testing it many times it works now. I have no idea perhaps a MQTT issue?

So i have only the question "is it harmful to use &PS to often for the ESP rom?"

Thanks and best regards, Stefan

[Aircoookie]

Hi Stefan, there is an old feature that allows you to toggle if the power state (on/off + brightness) should get adjusted when the preset is loaded or ignored. The new JSON API ignores this feature, so brightness is always applied. That is the reason it works in the web UI. To make sure the power state is always honored, add &PA=1 to the MQTT command.

Using &PS will always write the preset to flash memory, which can wear it out. Typically the memory can be written to more than 10000 times but you should make sure that you only use it if you actually want to save a new preset or overwrite one.

Kindest regards Christian

[StefanRu1]

Ok, thanks for your answer. With &PA = 1, you mean that i use &PA with my preset number? I use number 16 ;-)

10000 times sounds not so good for my solution. I want to store the settings before i do something with the lights in my home automation and restore it afterwards. I use the light with a motion sensor and with some alarm devices.

Would it be better to read the actual brightness + rgb value from the MQTT device and set it again afterwards or will this also wear out the memory?

If this is a better solution than a value is missing for my plan in the MQTT api. I would need a reading to directly get the FX value to also restore this afterwards. Getting it from the XPI XML is a little bit complicated.

Best regards, Stefan

[Aircoookie]

No, always just set &PA=1, it just toggles the feature on :)

Hmm, indeed, for that usecase, presets are not ideal.

Reading out the current brightness and color, storing them in your automation and then restoring them afterwards is indeed a good solution. It will not wear out the flash.

I agree, right now the API is not straightforward. I really want to add the JSON API via MQTT, but there were a few issues with buffer sizes being too large.

Another option would be to remove the commit(); in line 656 of wled01_eeprom.ino, which means that the preset is saved in RAM only and not written to flash. If you do that, you can save presets as much as you want without fear of wearing out flash. The only drawback is that if you actually want to save a preset, you have to go to any WLED settings page and save it once to write the presets to flash, otherwise they will not "survive" a reboot.

I hope it helps :)

[StefanRu1]

Ok,

so the API documentation is wrong? &PA= | 1 to 16 | Applies brightness from preset | 0.4

Ok, storing the parameters was my first idea. But would it be possible to add a topic for FX too? I mean like: wled/schranklicht/g:.* brightness only for FX? This would be enough for me to read everything out and store later.

The third option sounds for me very good. I have an Idea, what do you think to have one preset to store temporary? So lets say 1-15 for permanent preset storage and 16 for temporary preset? This would be great.

P.S.: I checked the coding you told me. Is it correct to change 656 to if (index < 16) {commit();} to have only preset 16 not written to ROM? So that it will not wear out?

Thanks and best regards, Stefan

[Def3nder]

Hi @Aircoookie, hmm - maybe it's time for PR #617 😅

...for Home Assistant users at least the MQTT message content should be JSON - this can easily be used in NodeRed for example. The XML cannot.

[StefanRu1]

Mhh,

i tried the code if (index < 16) {commit();} But also with this code the settings saved with set myMQTT2Client publish wled/all/api PS=16 survive a power cycle. So it seems it is stored in ROM.

any idea?

Best regards, Stefan

[Aircoookie]

@Def3nder you are correct, it's about time that MQTT supports JSON! I was waiting for #207, but I'm not positive that having as many topics as proposed there won't hurt performance. I will merge #617 soon (i will make a few changes so that json is not published to /v, but a new /j topic and see if i can get segment publishing to work somehow with topics /s/0 to /s/9)

@StefanRu1 that code should work fine... did you powercycle by saving Security settings (or saved any settings page before power cycling)? If that's the case, the settings saving action will have saved the preset to flash, not the actual PS=16 command :)

[StefanRu1]

Hi Christian,

i tried booth, but perhaps i mixed something up. I will try this again.

But i had some stability issues with my self build version when switching to FX and back to Solid. I build as described with Arduino Core v2.5.2.

All libraries where from i added last year when building. I had to get one new one, i think it was "AsyncTCP".

Is there a list what versions of libraries are you using for your official build?

Best regards, Stefan

[Aircoookie]

Hi Stefan,

thank you! hmm, other people have reported some stability issues as well when changing FX in 0.9.1. You can try updating to the latest Github master, I optimized the memory usage for more stability. Also updating the libraries mentioned in the Quick start might help. An easier and always up to date alternative to arduino IDE is Platform IO in Visual studio Code, it will automatically install all libraries for you :) You can also take a look at the platformio.ini file to see what library versions we are using for releases.

Kindest regards, Christian

[StefanRu1]

Hi Christian,

i had no stability issues with the official released 0.9.1. Only with my self build one. So i think it is a problem with versions in my Arduino IDE.

I will try the Visual Studio way.

Is the solution with having some not persistent presets something what makes sense for the official build? I am asking because i am still wondering if i should work with presets, or just read the actual values, store it in variables in FHEM and set it again after the execution.

Thanks, Stefan

[Aircoookie]

Hi Stefan,

hmm, you could also try if Arduino core 2.6.1 or 2.6.3 makes a difference. Visual studio uses 2.6.3 :) I don't believe non-persistent presets would be the best idea (as people will save to it and wonder why it doesn't retain). If anything, that could be added as an option though :) Both solutions are good for your use case!

Greetings, Christian

[StefanRu1]

Hi Christian,

thanks for all your help. I have build now with Visual Studio and the code change and it seems to work fine now!

My build for d1_mini is 559kb. Your Binary WLED_0.9.1_ESP8266.bin is 535kb. Do you know why i have this difference in size? I normally take your WLED_0.9.1_ESP8266.bin build for my D1 mini and it works fine.

I understand why you do not want a non persistent preset in the normal build. I do not know how much space a preset requires. Would it be possible to have a special preset which is not visible on the WEB UI. Just for automation tasks? Let's say preset 99? It is a lot easier to save and reload a preset than storing all the single values in a home automation. E.g. this is now my setting for a Alarm light: { fhem "set myMQTT2Client publish wled/all/api PS=16"; fhem "set myMQTT2Client publish wled/all/api A=255&FX=48"; fhem "sleep 8; set myMQTT2Client publish wled/all/api PL=16&PA=1"; }

Best regards, Stefan

[Aircoookie]

Hi Stefan,

awesome! I just tried compiling latest master myself and I am also getting 559kb. The reason for the increased size is that the platformio.ini was recently refactored and we forgot to re-add some defines that reduce the size of the infrared library. I will add these back in tomorrow. Don't worry, it shouldn't affect anything but binary size.

Hmm, i am not a huge fan of adding a setting for it because it probably won't get used much and just confuse users, but I see your point in the preset system being useful to restore a previous config. believe I have a good solution. Let's just make a new API command, &NP, and when that is used together with PS like PS=16&NP the preset is not commited to flash. I will add this tomorrow and let you know for testing :)

Greetings and good night! Christian

[StefanRu1]

Hi Christian, that sounds great!

Thank you! Stefan

[Aircoookie]

Just added it :)

[StefanRu1]

Wow, thank you so much. I will test it tomorrow. Stefan

[StefanRu1]

It did not leave me in peace, so i build and tested it. Size of the file is now correct and it works like a charm!

Thanks for explaining everything and showing me the VS build, this is so much easier than the hassle with the versions of the libraries in Arduino Studio.

Thank you a thousand times. Stefan

[Aircoookie]

You're welcome! I'm very glad you like it so much :) Christian