@Hub

I am happy you find the improvements useful!

Thanks.

Regards,
Klemen

@SteveV Hi!

You mean you cannot enter IP address due to not having any period ('.') character available?

This is not normal. Can you try changing the keyboard from Android settings and see if the issue persists?

I am "forcing" the number keyboard when user touches the IP field... In most cases, the keyboard also shows other characters. Anyway, I will fix this ASAP - I have a release lined up right now. I will probably take a day or two...

Best regards,
Klemen

@Bernard Yes, you have wrong credentials. This is what's causing the problem. You have changed the settings somehow...

I advise you to clear application data or uninstall and reinstall the application. This will reset the settings to default. Alternatively, you could input the correct settings, but I recommend reinstall... It will be easier for you. Then retry pairing.

Note that you must keep the default settings if you want to connect to GUI-O server!

Best regards,
kl3m3n

@enniom said in Some issues and possible improvements:

Hi Kl3m3n,

Some feedback from various tests, ideas, etc.

1. The new Bluetooth method and speed for connecting and reconnecting that’s been implemented works very well – thanks. That saves some frustration.

2. I’ve been using the Time Chart widget and found a few things to point out:
   a. Code;
   "|CH UID:ch22 YASC:0 VIS:1 X:65 Y:32 W:65 H:15 DRA:0 BGC:#000000 FGC:#FFFFFF CHT:0 CDTF:'HH:mm' BSZ:7200 FSZ:0.8 RAD:1.5 BTH:0 LT:0.2 XTC:8 XMA:5.0 YMA:3.0 YLO:1.5 YHI:5.0 YTC:9 VLP:1 DRAT:0.2 PZO:1 SHVL:0 CHN:'Values' SCI:1"

This chart will not show the y-axis with decimal points – only whole numbers. I don’t know if the decimal points were to be activated by VLP:1 as included in the definition?

VLP applies to last value label (currently makes sense only with SHVL:1), not the axis. I could extend this so that VLP also applies to Y axis labels.

b. If the definition is changed only by SHVL:1, then, if the y-values are greater than YHI, the graph is rescaled even though YASC:0. Maybe this override is needed to show the value at the right hand side of the Chart?

I cannot reproduce this issue. If I create a chart:

"|CH UID:ch0 X:50 Y:50 YASC:0 SHVL:0\r\n"

then add a few points:

@ch0 YP:"1"\r\n
@ch0 YP:"5"\r\n
@ch0 YP:"20"\r\n

and set SHVL:1, the chart does not rescale.

3. I understand from the Manual that the display properties needed to calculate the aspect ratio can be found using developer mode. It may be interesting to add a command that, after @init, the Android device can be polled to get the DPW and DPH values. This way, the uC can calculate the aspect ratio and set it to a value as part of the configuration.

[EDIT] Thinking more about this, it may be best to simply include the DPW/DPH values as part of the @init response. That is, something similar, for example, as the response to the RTC command: eg, @init 300:600. The uC can then choose to use or ignore the values in calculating the aspect ratio.

The ASR ration needs to be set to the value of the device, where the GUI is developed (only once). This ensures that the widgets will retain their correct aspect ratio even on different devices. If you always use the ASR of the current device, you negate this feature and the widgets will be scaled wrong (ASR should not be used in this a way). So, adding the option to retrieve this would probably introduce more issues by confusing the user.

4. In cases where widgets are defined on each of the 5 pages (0-4), it seems that if a widget is defined for page 0 as VIS:1 SCI:0, then those widgets appear on all pages. I worked around the issue by first defining the widgets as VIS:0, then toggling them on by VIS:1 when page 0 is revisited. This does not happen for pages 1-4.

If I send the following commands, everything seems ok - each widget is on its own page (i can then navigate through pages using @sci SCI:<index>):

"|TG UID:tg0 X:50 Y:50\r\n"
"|SL UID:sl0 X:50 Y:50 SCI:1\r\n"
"|CB UID:cb0 X:50 Y:50 SCI:2\r\n"
"|NI UID:ni0 X:50 Y:50 SCI:3\r\n"
"|TI UID:ti0 X:50 Y:50 SCI:4\r\n"

Can you please post the commands to reproduce your issue?

E

@mathieu Hi.

I will take a look at your initalization and see how the issue can be mitigated. I will get back to you.

Some Esp32 variants support classic bluetooth also. Here is the GUI-O example:
https://www.gui-o.com/examples/gui-o-and-boards/esp32#h.91so3s2tov2e

Best regards,
Kl3m3n

@mathieu Hi!

Is it possible for you to send me the initialization commands, so I can reproduce your issue and try to solve it? You can send them to info.guio.app@gmail.com.

Did you consider using legacy Bluetooth (not BLE, but Classic), which is more suited for such large payloads?

Best regards,
Kl3m3n

@mathieu Hi!

I can see only 29 widgets in the log, which means GUI-O did not receive commands for other widgets.
I am guessing that there is a problem with message loss (too much data in a short interval) due to limited buffer space of the BLE stack.

But, as you've said - adding a "short" delay did not help. Can you try adding a larger delay just for testing? You can add it after every 3rd command for example.

You could also try updating the connection parameters (decrease connection interval) after the connection is established (using pServer->updateConnParams method):
https://github.com/espressif/arduino-esp32/blob/master/libraries/BLE/src/BLEServer.h#L78

Also you can try more structured approach by sending a "chunk" of data (e.g., 100 bytes - without breaking the individual commands) and then waiting for a short time before sending the next chunk.

Best regards,
Kl3m3n

@mathieu Hi!

Can you try the following:

1. Open GUI-O app and navigate to "Info" from the settings menu
2. Tap the app version info 10 times - this will enable developer mode
3. Scroll to the bottom, tap on "Developer mode" and enable "Log incoming messages".

Next, try sending the widget commands then exit the app and connect your device to a PC. Navigate to com.guio.app folder (Android - > Data) and observe the contents of the incoming log. You can post the log here.

Note that the log will be truncated / cleared next time you start GUI-O app.

Best regards,
Klemen

@enniom Hi,

this is by design - if you have multiple devices, the last connected device is not necessarily the device user wants to connect to when starting the app... I can make this an option though in the Bluetooth settings. It would be useful in some cases, I agree...

Best regards,
Kl3m3n

@enniom Hi!

Thank you for the feedback, I appreciate it greatly.

I will check the issues you've pointed out and will get back to you shortly. Then we can discuss (and solve) them.

For DPW/DPH it is better to add a new command to keep the backward compatibility. I suppose users handle the @init message differently (e.g., using entire string for comparison, not just the starting characters) - I must not break this.

Best regards,
Kl3m3n

Our services will have scheduled outages on Nov 5-8, from 8:00 to 13:00. We apologize for the inconvenience and appreciate your understanding.

@Fehr No problem!

I plan to write a FAQ page on GUI-O website, which will also include this explanation.

Best regards,
Kl3m3n

@Bernard Hi.

Navigate to "Info" and tap on "Powered by GUI-O version..." 10 times. A new menu will appear at the bottom.

You can see the Developer mode section in the manual for detailed information.

Best regards,
Kl3m3n