INTERNET HEATING MANAGEMENT - PART 3

jap

In the first part, I described the basics: I created a switch on the local GUI-O and described all the necessary settings so that it also works as an IoT - via a remote GUI-O. In the second part, I added the functionality of a thermometer, thermostat, created other graphic elements, set parameters, images, video. In the third part, however, follow the corrections of the mistakes I made. I will also add some important parameters.

Določanje formata ekrana ASR

As I mentioned in the first part, the weekend management interface was also given to my wife on her phone. At the end of the second part, I wrote down my satisfaction, but when I saw the picture on my wife's phone, it was clear that something else needed to be done: Temperature display UID: lb_tmp went over the edge of the base UID: temp_container. The cause is in different screen formats. The wife has a more modern phone with a more elongated screen. The consequence is obvious. Graphic elements whose size is tied to the vertical dimension are larger in width here. With font size, this is obvious. I had a bit of a pitch in developing it because I was working on an older screen design. In principle, we need to predict what the screen format will be for most users. If you work for the market, I advise you to choose a modern format.

How It Works

The GUI-O application follows commands and cannot know if something is going over the edge intentionally or because of a different screen. The GUI-O determines the sizes according to the screen used, if we do not specify the format with the command. Therefore, the image where we develop is always consistent with our settings. The result is, of course, different on different screens. The solution is simple: Before we start developing the GUI, or before setting the W and H parameters to the graphic elements, we need to fix the screen format, otherwise we work on our own format. It is best to choose a commonly used format. Other screens will fill the extra space with a defined background color. This means that on a more elongated screen in terms of height, the GUI-O automatically adds a background color band at the bottom and top so that we get a reference format on the screen. Of course, this also applies to the width deviation - the wider screen gets a band right and left.

All interfaces must be given information about the reference screen - this is the ratio between the pages: ASR . The data can be read from the technical data of the screen, or it can be obtained from the ANDROID device via the GUI-O interface by turning on the Developer mode: Settings menu → Info → 10x by pressing the Application version. New settings are opened for the developer. Developer mode can then be turned off with this same interface. The ASR of our appliance is also displayed here.
I immediately added @guis ASR 0.5625\r\n to the initialization - after @cls\r\n:
Of course, the format must also be specified on remote GUI-O: @guis ASR: 0.5625 PUB: ""\r\n
My wife’s GUI-O interface got a white edge at the top and bottom. Both pictures: on my phone and my wife’s phone are now the same.

Screen dimming
The next problem and solution is completely user-friendly. The wife complained that the local GUI-O was lit at night and therefore could not sleep. Of course I solved the problem. I did a screen dimming. In the second part of the blog, I made different interfaces: on the remote interface, a BT UID: bt1 ... button has been added, with which we can look at the current temperature. The thermometer or uP against the mqtt server does not emit a constant temperature, so that I do not cause data traffic unnecessarily. There is no such BT on the local GUI-O. In the same place on the local GUI-O, I put another |BT UID:bt2 ... to dim the screen. I added to the local GUI-O initialization:

sendstr2("|BT UID:bt2 X:90 Y:57 W:15 H:8 BGC:#a4d4e2 SBGC:#54b2cd RAD:3 SHE:1 SHHR:1 SHVR:1 SVAL:\"tipkal\" FSZ:10 TXT:\"<b>ZA</b>\"\r\n");

Dimming is very simple: In response to the newly initialized @ bt2 1\r\n clear the screen and place a new large (full screen) |BT bt3 in the middle, where I specify all black colors.

else if (!strcmp(argument[0],"@bt2")) {//new button response on the local 
  sendstr2("@cls\r\n");//clear full screen - all GUI elements 
  sendstr2("@guis ASR:0.5625 BGC:#000000\r\n");//reference format
  sendstr2("|BT UID:bt3 X:50 Y:50 W:110 H:110 FGC:#000000 BGC:#000000 SBGC:#000000 SVAL:\"tipka3\" FSZ:10 TXT:\"\"\r\n");      //full screen black button  
  }

The response to @bt3 1\r\n is to re-initialize the entire interface, which I do in the same way as after loading SW.

else if (!strcmp(argument[0],"@bt3")) }//full screen black button response
  init_request = 1; //an event that triggers reinitialization in processing() in the same way as @init 
  processing();    //analysis otherwise triggered \n\r - at the end of the string
  }

The project is complete, HW installed on the cottage. Fixes and new functionalities will be in the following articles.

Sources: