Work has been ongoing on the energy local community hydro smart grid project I mentioned above.
I thought I would share a bit about the hardware/software architecture that Im working on for the project. A large part of it is basically the same as the OpenEnergyMonitor system, but there are also other parts to it such as the smart meter integration and project specific front end dashboards which are additional.
A part that might be of particular interest is the integration with Sonoff S20 smartplugs and the OpenEVSE that @glyn.hudson has been working on. This project required a way of scheduling appliances based on a day ahead forecast of power availability (either hydro or off-peak electric). So that the user can say, as an example: ‘I need to charge my car for 6h, with a completion time of 8am tomorrow’ and the software works out when the best time to charge will be, ensuring that even if there is only 3 hours of surplus hydro the car will still charge for an additional 3h with a priority for off-peak times if available.
This could be a useful feature for comination with @glyn.hudson’s OpenEVSE solar diversion charge mode so that even if the car was only partly charged from diverted solar during the day the charge algorithm could decide to complete the charge at the next best time e.g night time off-peak so that the car completes the specified charge time.
Before I dive into this topic in further detail, it might be useful if I first outline the wider software and hardware architecture proposed for the project,
- Close to real-time billing grade meter reading
- Hydro and community demand aggregation
- Smart device control in the home for automated demand response
- Mobile, tablet, laptop user interface as an in home display both for reporting and control setup.
Household billing meter and meter gateway
On the left we start with the household billing meter and meter gateway provided for by the meter operator which provides near real-time meter reading both of half hourly energy consumption and 5-10s real power measurement. Meter readings are passed to the hub over WIFI using the MQTT protocol.
The meter gateway is also connected to a LoraWAN network ran by the meter operator which provides a seperate upload route for half hourly meter readings.
The CydYnni server hosts the web accessible CydYnni app, see develop.cydynni.org.uk for the latest version going live soon. Emoncms is used as the data backend, which also provides features for data syncronisation between the hub and remote server.
The CydYnni server fetches half-hourly hydro, community and household half hourly data as well as daily and monthly summaries from the E-power server HTTP API.
What is called the hub in the project is an OpenEnergyMonitor EmonBase with the latest emonSD software stack as its starting point. The local version of the CydYnni app sits on top of EmonCMS on the EmonBase providing a tailored user interface for the CydYnni project, accessible from: cydynni.local.
The ongoing work on emoncms device integration (see Development: Devices, Inputs and Feeds in emoncms) provides automatic device configuration and an authentication mechanism for WIFI devices such as the meter gateway and sonoff plugs.
A key new component is the emoncms demand shaper module. Which as mentioned above uses a day ahead power availability forecast and user set schedules to determine the best time to run household loads.
The source code for this module can be found here: https://github.com/emoncms/demandshaper.
This is what the module ui looks like:
The module has a background process which processes the configured schedules, setting the control device state as an emoncms input value. The control device subscribes to a MQTT topic e.g emon/smartplug/state and switches on and off accordingly. A future version might have the schedule itself transfered to the smartplug or openevse charger so that the device can run independently of the hub for a certain amount of time in the event of coms failure etc.
This is what the same interface looks like inside the Cydynni EnergyLocal app frontend:
The next steps in terms of development are:
- to test the demand shaper thoroughly
- ensure it works seamlessly with multiple control devices
- create a cut down simplified EmonESP UI for the project running on the SonoffS20 plug.
- OpenEVSE integration
I will post another thread soon with details of how to get the demandshaper module up and running with a SonOffS20 plug for anyone interested.
The source code for the front-end app is available here: