Edit the file /boot/config.txt and add the following lines to disable Wifi and Bluetooth:
dtoverlay=disable-wifi
dtoverlay=disable-bt
My personal knowledge base, online.
Content about the Internet of Things and the digitisation of our home.
Edit the file /boot/config.txt and add the following lines to disable Wifi and Bluetooth:
dtoverlay=disable-wifi
dtoverlay=disable-bt
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!
First, kill all docker containers. Then remove them, and remove their related images:
docker kill $(docker ps -q) && docker rm $(docker ps -a -q) && docker rmi $(docker images -q)
Then we get the latest version of the docker-compose from GitHub:
wget https://github.com/eclipse/ditto/archive/refs/heads/master.zip
unzip master.zip
Unzip it, browse to the right directory, and start it:
cd master/deployment/docker
docker-compose up -d
Don’t forget to adjust the 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
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).
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.
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.
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.
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.
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.
Shelly devices are very active on MQTT: they send an update of their status by default every 30 seconds, even when the status didn’t change. Use the following HTTP command to change the update period:
http://x.x.x.x/settings?mqtt_update_period=300
In this case I chose 300 seconds, 5 minutes.
To configure a fixed IP address on the HUE bridge, you need to browse to the bridge using:
http://x.x.x.x/api/[bridge-user]/config
Use a HTTP PUT command to configure the IP address and use as body:
{ "ipaddress":"[new-ip]", "dhcp":false, "netmask": "[network-netmask]", "gateway": "[network-gateway]" }
Alternatively, you can use the HUE app and change the network settings in the bridge configuration.