Download Ditto from Github and unzip it in your favorite directory:

cd /data/install
wget https://github.com/eclipse/ditto/archive/master.zip
unzip master.zip

Adjust the nginx password:

openssl passwd -quiet
 Password: <enter password>
 Verifying - Password: <enter password>

Append the printed hash in the nginx.httpasswd (in the same folder as docker-compose.yml) file placing the username who shall receive this password in front like this:

ditto:A6BgmB8IEtPTs

Configure the docker data directory in /etc/docker/deamon.json:

{
   "data-root": "/data/docker"
}

And finally, install Ditto using the Docker compose script:

cd ditto-master/deployment/docker/
docker-compose up -d

To automatically start Ditto at system start, and clean up the related log-files and the following two lines to crontab:

crontab -e

@reboot sleep 30 && cd /data/docker && find . -name "*json.log" -type f -delete
@reboot sleep 60 && cd /data/install/ditto-master/deployment/docker && sudo docker-compose up -d

Done!

When a Shelly (1PM) device boots in developer mode it shows its status and power usage in JSON. You can put the device into normal operational mode by sending the following HTTP command:

http://x.x.x.x/settings/developer?selftest_done=1

Reboot the device and it’s webinterface should show up:

http://x.x.x.x/reboot

When we decided we wanted to build a new house I wanted to invest in both passive and active technology to reduce our energy consumption as much as possible. My goal is to reduce our dependency from external energy sources, without installing batteries. This means I need to match our energy consumption with its (local) availability (or simply said: solar-powered production).

Use case

The washer, dishwasher, and dryer are energy-consuming devices. We are used to start these devices at night: the energy was cheaper, there was no noise pollution in the living room, and it made sense at the end of the day.

At the same time, it doesn’t really matter when these devices finish their work. Typically you want them finished within the next 12 hours or so. Therefore, a smart system could nicely plan their consumption based on the next available solar-power production peak, which typically happens around lunch-time anyway. This would increase the energy we consume directly from the solar panels and reduce the energy we need to consume from the grid.

To make things a bit easier I decided to buy devices that support the B/S/H Home Connect system. As we are still building the house I don’t have a dishwasher and at the moment we don’t use a dryer, so I started with the washer.

Challenges

I need a lot of information to make this work. Luckily there are some public (free-of-charge) cloud-services available that helped me a bit here and there. All of the selected services have well documented APIs that I could implement with ease. My biggest challenge was to get the OAuth 2.0 Device Authorization flow up and running for Home Connect.

• Appliance status to determine if there is a need to start a program.
• Solar-panel production prediction, at least 24 hours ahead.
• Solar-power production past, to validate quality of the prediction.
• Appliance program consumption pattern to match it against the prediction.
• Some user interface to notify me what is happening.
• [optional] Day-ahead energy pricing, in case the production is not sufficient to select an optimal (cost-efficient and grid-optimised) timeslot to consume energy from the grid.

In our current apartment I don’t have solar-panels. Therefore I’m using data from another (live) solar production site to simulate the behaviour of the concept.

System architecture

To manage expectations: I’m not a professional software engineer. I’m not planning to productise this, and just want to be able to maintain everything myself. I might publish some of the related projects on Github, but don’t expect a lot of documentation on it.

The image below shows a high-level system architecture. I’m using Ditto as a local digital twin for capturing the current state of all the entities in the system. Additionally, I’m using InfluxDB to store the historical states of the digital twins and Grafana to visualise the historical states. The green services are “sensors”: they retrieve data from their sources and update the digital twin. The blue services are “controllers”: they control the devices based on the status of the digital twin. The orange services are “processors”: they transform data or decide to start actions. The red services are “communicators”: they communicate with the user of the specific use-case.

How to use it?

Well, that’s the good news. Instead of pressing the “start” button on the washer, we press the “remote start enabled” (or “app”) button. The HomeConnect.Sensor captures this event and updates the digital twin. The HomeConnect.Planner is subscribed to this update and starts calculating the best possible timeslot in the next 16 hours to start the program. It considers the predicted solar-panel production, the history washer program consumption registered by the Shelly Plug, and the Epex spot pricing. Once it has calculated the ideal start time updates the “scheduledprogram” digital twin. The HomeConnect.Controller is subscribed on this update and sends the start command to the washer based on the time HomeConnect.Planner has defined. Slack (using Slack.Messenger) keeps the user up-to-date on what is happening, for example, when the program is planned, started, finished, or cancelled.