Project JEspOs

JEspOs

Joba's ESP OS - a kind of operating system for ESP8266 based boards.

Goals

• Describe or script installation of PlatformIO
  • Install Atom rpm
  • Install Atom module PlatformIO
  • Install the ESP8266 core for PlatformIO
• Configure PlatformIO to contain all necessary arduino/esp libraries
• Provide a library for each subsystem an esp8266 may need to operate
• Operate means: listen for requests (from serial, web, mqtt, udp, ...), collect data, send data, operate peripherals (leds, relays, buttons, sensors, ...)

Subsystems

Design Principles

Jespos should provide a subsystem library for each topic. The libraries should be very easy to use. Each library should provide a class to provide the functionality. There should be a constructor for that class taking only arguments really needed during object construction. Then there should be an init method taking arguments to bring the class in a running state. Finally there should be a handle method, called in the main loop, that does the actual work. All methods of the class are not allowed to block. Blocking tasks are done asynchronously. There will be a worker subsystem that will help with that. All classes will avoid using dynamic memory as much as possible. Classes should be as independent from other topics as possible and explicitly name dependencies. Classes should be designed in a way that they can collect data they provide via network until a connection is available.

Topics

Persistence

Each subsystem can allocate some (small) space that should be reboot safe. It is stored in rtc memory

Sleep

Each subsystem provides a handler that is called before the system can go down. The handler returns true if it is ok to go to sleep. Awaking is just a normal reboot, so a subsystem should store everything it needs to restore its current state via the persistence module.

Update

Subsystem providing OTA update capability. Also calls the shutdown handlers before an update is done.

Communication

Subsystem to handle multiple input and output channels and dispatch incoming requests. Each channel will get its own subtopic (serial, mqtt, ...)

Sensors

Most sensors need some setup tasks, then get data either continuously or on request. Some provide an interrupt if data is ready. This subsystem provides an interface for these patterns. The details are handled in derived subtopics which will usually use external libraries for the specific sensors.

Logs

Provide a uniform way to print logs that are seen on serial or syslog.

Buttons

handle button press events with debounce, inform modules about events like pressed, released, pressed since..., released since .

LEDs

Manage access to leds or similar (relay, ...). Switch them off, on, blink with some frequency and x repeats, request current status (on/off and busy/free).

Monitor

send out status info (voltage, uptime, ip, ...) at startup and on a regular basis via communication channels

WLAN

Auto connect to configured WLAN as STA. Also provide AP to configure new STA WLAN parameters.