Let's Control It

Device: Wemos D1 mini pro
Build: ESP_Easy_mega-20200328_normal_ESP8266_4M1M.bin
Location: Rules

There does not seem to be a way to swap between rule sets. If you use the selection list (now at the bottom of the screen) nothing happens - it stays on Rule Set 1

I get exactly the same problem - can't change to another rule set.
I suspect the drop-down buttons aren't working.

This already has been fixed, I still need to trigger a nightly build, but Travis is acting up.
The Travis integration is not working right now and I have already opened an issue with Travis support, but they are not really quick to respond
As in I opened the issue over a week ago and after a few emails I have had no reply since.

Something seems to be really wrong with the Travis integration and our GitHub account as I don't see any of the suggested options given in the many online guides.

I've just dropped back to 20200310

Can you test this test build: https://www.dropbox.com/s/6opy7escewqau ... 2.zip?dl=0 ?
It has also other changes included, so please let me know if you find anything strange.

N.B. See here for more info on the chnages: https://github.com/letscontrolit/ESPEasy/pull/2972

Hi,
I've tried the following FW on a WeMos D1 Mini and can confirm the Rule Set selection is WORKING again.

ESP_Easy_mega-20200328-15-PR_2972_normal_ESP8266_4M1M.bin

dynamicdave wrote: ↑02 Apr 2020, 08:26 Hi,
I've tried the following FW on a WeMos D1 Mini and can confirm the Rule Set selection is WORKING again.

ESP_Easy_mega-20200328-15-PR_2972_normal_ESP8266_4M1M.bin

Does the drop-down appear on the top for you ? (when in full screen, desktop) \\

-D

In full-screen mode it appears at the BOTTOM with a window showing the rules to the RIGHT.

If I reduce the width of the window, then it moves to the TOP of the screen.

I don't have an issue with that behaviour.

David

I can confirm it works and like Dave in full screen mode, the drop-down appears to the right at the bottom. It does use a 'bit' of space though.

This release also fixes the '%sysbuild_filename% misingString' issue https://www.letscontrolit.com/forum/vie ... f=6&t=7574

I did notice that as of mega-20200310 on the Main tab you see
Free Mem: 21936 (34568 - )
Free Stack: 3664 (3824 - )
where mega-20200305 and prior releases had this
Free Mem: 18024 (17344 - sendContentBlocking)
Free Stack: 3680 (2064 - sendContentBlocking)

I'll keep looking for other issues
- Main tab - Git build value missing

That's still something I need to fix indeed.

- Main tab - Git build value missing also missing in JSON (probably for the same reason)

haven't noticed anything else obvious (smile)

interestingly the rules full screen crop down going to the bottom is the same in mega-20200305

TD-er wrote: ↑03 Apr 2020, 10:11 That's still something I need to fix indeed.

We should start focusing on getting the new GUI released.

found two more things
minor - in System Variables - %iv4% shows up twice and %ip% is missing

major - controler 2 is not working - I went back to the 20200310 version and it worked fine

dampa wrote: ↑07 Apr 2020, 18:46 found two more things
minor - in System Variables - %iv4% shows up twice and %ip% is missing

major - controler 2 is not working - I went back to the 20200310 version and it worked fine

Can you be a bit more elaborate on this one?
And maybe even add an issue for it on Github?

Using ESP_Easy_mega-20200310_normal_ESP8266_4M1M.bin
Setup Controller 1 as a local network MQTT controller
Setup Controller 2 to use mqtt.beebotte.com

If I enable controller 1 and disable controller 2 it works
- - C1 - - || - - C2 - -
enabled || disabled - C1 works
disabled || enabled - C2 works

flash system using ESP_Easy_mega-20200328-15-PR_2972_normal_ESP8266_4M1M.bin
If I enable controller 1 and disable controller 2 it works
- - C1 - - || - - C2 - -
enabled || disabled - C1 works
disabled || enabled - C2 DOES NOT WORK

flash system back to ESP_Easy_mega-20200310_normal_ESP8266_4M1M.bin
everything works again.

do you still want a github issue?

Nope, that's clear enough for me to see what I may have mixed up.
Just one question, do you use login credentials for MQTT?

I've done a test here with the current state of the mega branch and using Domoticz MQTT it still works when I switch from C1 enabled to C2 enabled (and the other disabled)

So I guess it would be a good idea to discuss this on Github in an issue.

With mqtt.beebotte.com you must pass a token in the Controller User.
I'm using the Home Assistant (openHAB) MQTT

Edit: I swapped to Domoticz and now see a msg in the log
160779: MQTT : IDX cannot be zero!

once I swapped back to the 20200310 version it started working again...patially. I still see the 'IDX cannot be zero' msg and no automatic messages are coming thru, but a publish in the rules is working.

Swapping back to the Home Assistant (openHAB) MQTT

Ah found the issue... or at least it looks like something that may be causing it.

You can see it yourself, if you look at the "network" tab of the inspect window of your browser.
When you save it with changing the password, you will see the password as plain text.
If you toggle something else (without changing the password), it will be "*****" and I guess it will also be saved like that.

Beebotte doesn't use a passwoord, you put a token in the 'Controller User'

In comparing the webpage in the 20200310 vrs the 20200328-15-PR_2972 I see the new
Use Extended Credentials:
Controller Client ID:
Unique Client ID on Reconnect:
Current Client ID:
Publish Retain Flag:

are any of them now required?

This is not really on topic anymore, so I suggest to open a new topic about it, or an issue on Github as it will be next to impossible to find the discussion again later.
There should be a controller client ID set based on what it used to be if you don't set anything.
You can try something like this The checkbox for "extended credentials" can be checked if you need more than the old length of the credentials.

This looks all fixed in mega-20200410 :