ESPEasy & uPyEasy Strategy

[LisaM]

[...] For uPyEasy there is no need to do any JSON REST API encoding/decoding since everything is done by (another) (micro)python library. The input/output of these libraries (python dictionaries) match the input/output of the database (also python dictionaries), so it works together seamless.So little coding effort on my side.

I'll go ahead and make a proposal for a JSON REST API standard, based on the information i have in the uPyEasy database.

The reason for all of this is very simple: i need it. I want to have a dashboard displaying current values from uPyEasy, primarily on mobile devices.
Something like this:
[...]
The supernodes, the most powerfull nodes in a nodes mesh, will have this. The more simple ones probably not.

Great, so we already agree
I know creating an API like this is very easy in Python. (I do also use it at work)
And I know you already have a well thought of data-structure.
So it would be great to try to match both API-like interfaces to be able to use then together in the same ESPeasy grid/mesh, where possible.

It is not my intention to let the current datastructs of ESPeasy (C++) be the limiting factors for an API.

It would be great if ESPeasy C++ and Python could share some functionality like using recorded values of one node in rules on the other, or sync some actions and be integrated in the same web-interface to create a combined dashboard.

Done:
url: "/api/v1.0/controller/" + id,
type: 'DELETE',
And...working!
A few lines of code in the webserver framework was enough, searching how this supposed to work was the most time consuming.

I'll make an uPyEasy/ESPEasy RESTful interface proposal...

And start prototyping with a bootstrap (offline) dashboard retrieving current device values from uPyEasy.

Cheers,

Lisa

[TD-er]

ESPeasy C++ already has some JSON retrieval for the values. (sensor data also addressable per task)
Maybe good for inspiraction?

Code: Select all

{  
  "System":{  
    "Build":20102,
    "Git Build":"",
    "System libraries":"ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3",
    "Plugins":47,
    "Plugin description":" [Normal]",
    "Local time":"2018-05-09 22:07:00",
    "Unit":0,
    "Name":"ESP_Easy",
    "Uptime":965,
    "Last boot cause":"Manual reboot",
    "Load":28,
    "Load LC":12236,
    "Free RAM":13816
  },
  "WiFi":{  
    "Hostname":"ESP-Easy-0",
    "IP config":"DHCP",
    "IP":"192.168.1.75",
    "Subnet Mask":"255.255.255.0",
    "Gateway IP":"192.168.1.1",
    "MAC address":"A0:20:A6:19:2A:BF",
    "DNS 1":"192.168.1.1",
    "DNS 2":"0.0.0.0",
    "SSID":"Lurch4",
    "BSSID":"34:31:C4:B1:8D:C7",
    "Channel":11,
    "Connected msec":21684891,
    "Last Disconnect Reason":201,
    "Last Disconnect Reason str":"(201) No AP found",
    "Number reconnects":2,
    "RSSI":-73
  },
  "Sensors":[  
    {  
      "TaskNumber":1,
      "TaskEnabled":"true",
      "TaskInterval":5,
      "Type":"Display - OLED SSD1306/SH1106 Framed",
      "TaskName":"oled"
    },
    {  
      "TaskValues":[  
        {  
          "ValueNumber":1,
          "Name":"Temperature",
          "Value":24.61
        },
        {  
          "ValueNumber":2,
          "Name":"Humidity",
          "Value":50.27
        },
        {  
          "ValueNumber":3,
          "Name":"Pressure",
          "Value":1006.29
        }
      ],
      "TaskNumber":2,
      "TaskEnabled":"true",
      "TaskInterval":60,
      "Type":"Environment - BMx280",
      "TaskName":"bme"
    }
  ],
  "TTL":60000
}

The TTL I added at the highest level is to suggest a reload time in msec.

[grovkillen]

This approach works really good for my JavaScripts.

JSON is so nice to parse. Love it!

[LisaM]

ESPeasy C++ already has some JSON retrieval for the values. (sensor data also addressable per task)
Maybe good for inspiraction?

Code: Select all

{  
  "System":{  
    "Build":20102,
    "Git Build":"",
    "System libraries":"ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3",
    "Plugins":47,
    "Plugin description":" [Normal]",
    "Local time":"2018-05-09 22:07:00",
    "Unit":0,
    "Name":"ESP_Easy",
    "Uptime":965,
    "Last boot cause":"Manual reboot",
    "Load":28,
    "Load LC":12236,
    "Free RAM":13816
  },
  "WiFi":{  
    "Hostname":"ESP-Easy-0",
    "IP config":"DHCP",
    "IP":"192.168.1.75",
    "Subnet Mask":"255.255.255.0",
    "Gateway IP":"192.168.1.1",
    "MAC address":"A0:20:A6:19:2A:BF",
    "DNS 1":"192.168.1.1",
    "DNS 2":"0.0.0.0",
    "SSID":"Lurch4",
    "BSSID":"34:31:C4:B1:8D:C7",
    "Channel":11,
    "Connected msec":21684891,
    "Last Disconnect Reason":201,
    "Last Disconnect Reason str":"(201) No AP found",
    "Number reconnects":2,
    "RSSI":-73
  },
  "Sensors":[  
    {  
      "TaskNumber":1,
      "TaskEnabled":"true",
      "TaskInterval":5,
      "Type":"Display - OLED SSD1306/SH1106 Framed",
      "TaskName":"oled"
    },
    {  
      "TaskValues":[  
        {  
          "ValueNumber":1,
          "Name":"Temperature",
          "Value":24.61
        },
        {  
          "ValueNumber":2,
          "Name":"Humidity",
          "Value":50.27
        },
        {  
          "ValueNumber":3,
          "Name":"Pressure",
          "Value":1006.29
        }
      ],
      "TaskNumber":2,
      "TaskEnabled":"true",
      "TaskInterval":60,
      "Type":"Environment - BMx280",
      "TaskName":"bme"
    }
  ],
  "TTL":60000
}

The TTL I added at the highest level is to suggest a reload time in msec.

To big, i'll separate the parts into chunks like sensors and so on.
Changed security to Basic Http Authentication on uPyEasy so that the REST api can also use that.
The device and controller DELETE Rest API is working as POC, the remainder will be easy.

uPyEasy Dashboard REST client basics are set:
- Presentation and styling: Twitter Bootstrap
- REST request management: jQuery
- Templates and event handling: Knockout

These are all delivered through the CDN network. There's no need to have all the webpages sending from uPyEasy, so it won't. uPyEasy will only send the json data through the upyEasy REST api.

[TD-er]

I didn't know the "Twitter Bootstrap" yet, so I will read into it.

The reason I made the JSON loadable as a whole, and also per task is to make the load move to the browser, not the ESP.
A single query takes 30 - 70 msec and if you query all tasks at once, you can get complete the request also in 30 - 70 msec.
On the ESP8266 it simply takes that long to process. But when streaming has started, it doesn't take much time to deliver all at once and I'm generating the stream while it is being transferred.

How do you plan on knowing when new values are there to process?
I've looked into keeping a connection open, but that may give some issues, since the maximum number of open connections is quite limited.

And I don't know much about other existing push technologies.
So that's why I added the TTL attribute to the JSON, to hint when a new fetch would be in order.

Edit:
Isn't "Twitter Bootstrap" just "Bootstrap" ?
Or am I missing something here?

[LisaM]

Isn't "Twitter Bootstrap" just "Bootstrap" ?

Twitter created it, open sourced it and named it Twitter Bootstrap. It's becoming more and more just Bootstrap...
The reload time depends on the sensor delay time, if they are all 60s it doesn't make sense to reload every 6 s. So essentially the shortest delay time is determining the reload time.

[TD-er]

About the reload time, that's indeed what I output as TTL.value.
For the log view, the TTL is determined on the amount of entries read from the log buffer.