@Proto Hi!

Yes, you need a license for each Android device that uses a different Google account from the one used to purchase the license.

Licensing is based on the app, not on development. Specifically, the app does not track (and cannot enforce) which device is designated as the "development" device.

Best regards,
Kl3m3n

@kl3m3n

Thank you

Regards

@Sato No problem.

Best regards,
Kl3m3n

@Gemini-cricket-0 said in Help on pairing mqtt for esp8266:

@kl3m3n Hello

Thanks a lot for your help, I will try following your advice as soon as I have some time. Have a great day.

Best regards

If you have any issues, please let me know.

Regards,
Kl3m3n

@SteveV said in Purchased Pro but hasn't activated:

I unreservedly apologise for my mistake and sorry to have bothered you and wasted your precious time.

No problem 🙂

@SteveV said in Purchased Pro but hasn't activated:

Would you please advise what the license entails - how is it applied?

Please check the DEMO and PRO difference here:
https://www.gui-o.com/home#h.udqy5odkk9

Best regards,
Klemen

@Hub

I am happy you find the improvements useful!

Thanks.

Regards,
Klemen

@wolerdbon Hi!

So, when you connect GUI-O app (client) to the ESP32 (server) a persistent connection is established. If the server closes the client connection, client will detect this and show an error. If autoconnect is enabled client will try to reconnect every 5 seconds...

When you just "kill" the server, the client is not disconnected properly and no "goodbye" message is sent. That is why nothing happens on the client side (there are ways to handle this, e.g., keep-alive as MQTT uses for example, but this is currently not implemented in Ethernet connection.

If you try the GUI-O design tool (and exit when the connection is established), you will notice that the client (GUI-O app) reacts immediately, because when the tool closes it implicitly disconnects the client.

I can suggest you use "home" button. So, when you reboot the ESP32, swipe GUI-O from the left side of the screen to the right to open the settings menu. Press the "home" button in the upper right corner.

Hope this helps.

Best regards,
Klemen

Hello @kl3m3n,

Works good, thank you

Regards

@Hub Thanks 🙂

Hello @kl3m3n,

Thanks for the tip

Regards

Hi @kl3m3n,

It works perfectly, thank you very much.

You are the best! 💪

Best regards

@gašper-medved Based on some quick research, the DIP position are:

When programming:
USB UART connection with ESP8266 in programming mode (GPIO0-GND) - DIP 5 and 6 and 7 ON

When operating:
USB UART connection with ESP8266 - DIP 5 and 6 ON

Regards,
Kl3m3n

Hi @kl3m3n,

If not possible, it's ok

The long name can be part of a street name or if to long it can be in short form.
With the name i can immediatly know where the connection is to.

Regards

@VNB said in GUI-O with Nano 33 BLE and the ArduinoBLE Library:

There were two minor problems.
1.) The Slider Control knob always stayed at 100% even if it is set to a low brightness. That was fixed by adding the following instruction in the "led drive" section.
sendMsg("@brightness VIS:1 VAL:val\r\n");

The code:

@VNB said in GUI-O with Nano 33 BLE and the ArduinoBLE Library:

sendMsg("@brightness VIS:1 VAL:val\r\n");

is not correct (as you've already pointed out), since the val is a non-numeric string that GUI-O cannot convert to numeric string.

This is correct:

@VNB said in GUI-O with Nano 33 BLE and the ArduinoBLE Library:

sendMsg("@brightness VIS:1 VAL:"+ String(val) + "\r\n");

as the String constructor converts the val into numerical representation.

This code should not be necessary, since the value originates from CB, which should already have the correct position. The issue seems to originate from somewhere else, but I cannot see the problem...

Regards,
kl3m3n

@kl3m3n

Ok, thank you

Regards

Hello @kl3m3n,

The read how many lines exists in the files is no problem.
Next week i will see how to handle it with FAC and FP

Thank you
Regards

Your changes work great! THANK YOU for the quick response and new parameters in CB

@Sato Hi!

Google has strict policies regarding sensitive permissions (SMS included).
In order to handle SMS related functionality, the application needs to be (in general) registered as the default SMS app. Since GUI-O does not need SMS functionality to run, it would be probably quite impossible to convince Google to allow SMS features in GUI-O. You can read more about it here:

https://support.google.com/googleplay/android-developer/answer/10208820?sjid=7843560484419800904-EU

Regards,
kl3m3n

Hi @kl3m3n,

Thanks, I really have to change my glasses

Regards