"devices"

[mschnell1]

After reading the "roadmap" document and finally understanding the project structure concepts, I'd like to share some ideas.
I understand that a distributed system (I call it "EOS network") is planned and a rather "standard" protocol ("API") is to be used to have the system parts communicate.
In the concept,"devices" seem to be thought of as 3rd party thingies.
But those need to be connected to the EOS network. To do this, I suppose a set of small embedded units (IOT devices) is necessary to provide the hardware and software connections to (otherwise not compatible) 3rd party devices, and to be EOS-own endpoints (like temperature sensors, pumps, valves, wall-mounted User interface etc).
Right now (for other projects) I am researching on doing IOT thingies using the RP2350 CPU. Same IMHO is perfectly suited to to such devices. I prefer programming such firmware in Rust, but I do see that over here, everything is done in Python, and hence obviously that path is to be continued. Programming RP2350 in Python is pretty standard. There are several. very cheap boards featuring the RP 2350 (or still the slightly less powerful RP2040) chip. As we need networking, boards featuring LAN or WiFi or Bluetooth might be preferable (there also are several other networking technologies that might be useful for home automation). I don't suppose we want to built hardware.

[b0661]

Here is a picture of the overall system architecture:

and here a little scetch of the components of EOS:

You can see devices are in fact device simulations used for optimization of the energy scheduling plan. The IOT devices you are talking of are in charge to schedule real devices according to the optimized energy scheduling plan. How this is done is out of scope of EOS. The burden of controlling real devices is given to the integrations.

As EOSdash is an integration it may be extended to also talk to IOT devices to provide energy scheduling information. This was not discussed yet.

The other integrations seen in the figure (home assistant and Node-RED) are already prepared to talk to a plethora of devices.

[mschnell1]

I see. This is similar to what I expected.
Am I wrong to assume that only by connecting EOS to the real world it really becomes decently beneficial ?
I suppose the "REST API" connectivity has been implemented, as same is versatile enough to talk with all kinds of information senders and digesters, including those I mentioned (temperature sensors, pumps, valves, wall-mounted User interface etc) via any transport layers including wireless. As you say "integration ... extended to also talk to IOT ... This was not discussed yet", maybe I can contribute (in the company I work for we do such stuff since many years).

[b0661]

I see. This is similar to what I expected. Am I wrong to assume that only by connecting EOS to the real world it really becomes decently beneficial ?

Yes, for sure.

I suppose the "REST API" connectivity has been implemented, as same is versatile enough to talk with all kinds of information senders and digesters, including those I mentioned (temperature sensors, pumps, valves, wall-mounted User interface etc) via any transport layers including wireless. As you say "integration ... extended to also talk to IOT ... This was not discussed yet",

The REST API is there just to get the optimized energy scheduling plan. How control of temperature sensors, pumps, valves, wall-mounted User interface is derived from this is open to the integration or to the real device if it can handle the scheduling plan by itself.

maybe I can contribute (in the company I work for we do such stuff since many years).

You are welcome. You may create your own something that takes the energy scheduling plan and controls the real devices. Whether this is an integration server or a meshed net of devices or ... is not precluded by EOS.

[mschnell1]

You are welcome. You may create your own something ...

before creating anything, a decent plan should be agreed upon how the "system" (EOS plus extensions) should look like and how it can be brought into "production" for a decent group of end users.

Sounds good.
I suppose EOS also needs local sensor data such as temperature, household power consumption,...
Are the datasets EOS wants to communicate (via REST API) with local entities already defined ?
I suppose exactly those are used for simulating right now.

More "future" reasoning:

As the EOS team decided to use REST API (FastAPI) for communication and to use Python as software design tool,it is obviously a good idea to stick to that with any extensions.

AFAIU, REST API can be used via any data channel (such as TCP/IP)

I am rather sure, modern embedded devices (such as PICO2) are able to communicate via REST API, and are able to do as well simple stuff (such as collect sensor data and send them on request), as more complex stuff (such as control the central heating "according to the current energy scheduling plan" (either by being the "controller" itself or by setting parameters of the controller e.g. via CAN BUS ), and are able to "team up" to transport information wherever necessary.

[b0661]

Are the datasets EOS wants to communicate (via REST API) with local entities already defined ?

EOS does not want to communicate with local entities. EOS is passive. A client can request the energy scheduling plan from EOS. EOS generates the plan using the configuration and the measurement data that was set by the client. It is totally up to the client to do the right configuration and to provide the appropriate measurements for the optimization.

before creating anything, a decent plan should be agreed upon how the "system" (EOS plus extensions) should look like and how it can be brought into "production" for a decent group of end users.

Feel free to provide your ideas. You may have a look on other home automation systems that potentially may use EOS for energy schedule optimization (Home Assistant, Node RED, EVCC, ..).

[mschnell1]

OK. EOS being passive (i.e. a "Server" supposedly is a decent design decision.
So the peripheral units need to start any communication, such as pushing sensor data and request "optimization plans"
Perfect.
Nonetheless I suppose EOS will define the datasets it is able to communicate. The state / schedule of this is what I wanted to know. (I suppose the protocol used is already defined by the "REST API").
In fact I (pessimistically) doubt that the providers of commercial system will be inclined to adapt to such protocols/datasets any time soon. Hence dedicated "middle-ware agents" might be necessary to extract logging data from those and put parameters onto them using their (hopefully published) protocols.

[b0661]

Nonetheless I suppose EOS will define the datasets it is able to communicate. The state / schedule of this is what I wanted to know. (I suppose the protocol used is already defined by the "REST API").

See the documentation. It is not completely ready for public use and not every thing is working, but you should get an overview (see Server API - click on local to access your server running on local).

[mschnell1]

I see.
Can the Server that I already did start and could attach to by the browser be requested to send some data via that API ?
Maybe I'll find the time to do some software that attaches to it and try out what is involved at minimum.

[b0661]

Are the /v1/config endpoints not intended for a browser based GUI interface ?

All endpoints are for M2M using JSON.

[mschnell1]

I am just not up to speed with this. Up til nowI did not try to do any software on that behalf but just used a browser to access the EOS server.
Does that (e.g. with http://localhost:8503/docs ) mean that a client that is a browser, can request to get a html page (that might include JAVA code and s links to other locations) to be displayed to a human; while a client that is a "machine" can drop that stage and just request or send JSON "files"?

[mschnell1]

When accessed by a browser, after
"GET /docs HTTP/1.1"
The EOS Server reports
"GET /openapi.json HTTP/1.1"

So just doing " "GET /openapi.json HTTP/1.1" is what an m2m interface would.

When I blindly do that with a browser I get
{"detail":"Not Found"} in the browser and
127.0.0.1:58670 - "GET //openapi.json HTTP/1.1" 404 in the server

supposedly because necessary parameters are not sent with the request. Supposedly this is only possible by java script in a browser, but a "IOT device" could easily do that.

[Lasall]

With /docs you get the definition of the interface in a nice human readable way. The endpoints listed there you can access directly with other services (e.g. try /strompreis /optimize etc.)

[mschnell1]

Yep. looks good.
with /strompreis I get al list of numbers:
[0.00031664,0.00030899,0.00030571,0.00029945000000000004, ... ,0.00034486,0.00033748999999999997,0.00033120000000000003,0.00032490000000000004]
perfect!

Obviously the "endpoints"are defined in indocs\akkudoktoreos\openapi.json . Correct ?

(optimize klappt nicht,vermutlich weil noch gar nichts gerechnet wurde)