I would like to be able to ask my mobile phone or Google Assistant (also Google Home) directly whether I can actually go jogging or not. Decisive for this is actually only the water level of the river nearby. Sure - a quick look at it would be enough, but my primary concern is the fiddly work and the question of whether I get this task done with the means of modern digitalization.
In this article I would like to give an overview of what can be implemented quickly and easily with "enterprise" tools such as Rancher2, Kubernetes, Docker, DialogFlow and OCR, even in a small leisure setting. It should not be seen as a step-by-step guide to recreate something similar. That would go beyond the scope of this article and there is very extensive documentation on the net for all topics listed below.
After a short search in the net I found what I was looking for: An official website publishes the water level at 15-minute intervals at a monitoring station just a few kilometres away. Besides water level graphics, there is fortunately also a pure numerical table, which is only available as an image file.
After further research on the topic and the previous knowledge from the daily work with rancher, cubernetes and docker I finally came up with the following list of needed tools and started with the implementation:
A script that finds out the current water level and can be used to decide whether you can go jogging or not:
The script - the olive green deposited variables I pass from the Kubernetes environment.
A Go script of my colleague Matthias, which provides a webserver and executes a shell command defined via environment variable during a GET-call and displays the result. So here simply a "cat /mnt/pegelstand/pegelstand.json". This way I save a nginx or apache. The script is already available as binary in a docker. However, it should not be executed as a cronjob, but as a constantly available web server service.
I already have some Kubernetes clusters managed by Rancher2 available. So it is obvious to deploy the two above mentioned dockers on one of these clusters: The first one as cronjob, which is executed every 15 minutes and the second one as normal deployment. Keeping cronjobs and normal services in the same pod is not provided by Kubernetes - so I can't use an ephemeral emptyDir as volume, but have to use a normal directory from the host as shared volume.
After this was running I created a suitable Ingress under Rancher2 to allow external access to the JSON file. This includes the installation of the Certbot-Kubernetes-Charts to get letsencrypt-TLS certificates.
Screenshot of the project in Rancher2 that controls the Kubernetes cluster.
This was the part of the solution I knew least or not at all - so it's high time to learn about it: During my research about GoogleAssistant integration I stumbled over and over again over "api.io", which is now called "DialogFlow". The company was bought up by Google, is now part of the group, is very deeply interwoven with Google's API Console and is a kind of construction kit to model dialogue processes between the user and Google Assistant.
After logging in to DialogFlow, which as far as I could see is done exclusively through the Google account, you directly land in a well structured interface where you can create your first dialog.
From this point on there are numerous entry and exit points between the DialogFlow interface and the Google Cloud or Google API Console and the Assistant simulator. I haven't got deep enough into the system yet to be able to assess whether I could have realized the desired solution with Google onboard tools without DialogFlow, but it simplified the process considerably the first time around - at least that's how it seems to me at the moment.
The result is that you first have to get the Google Assistant to enter the right dialog - just like starting an app. Only then can you ask concrete questions, and you can influence the answers. My aim was to have my own answer read out of the JSON provided on the net. By adding a fulfillment object to my dialog, to which I can assign my JSON-file as webhook-URL, the whole thing went as desired.
This is what it looks like on DialogFlow.
It works! \o/ I can now address my Google Assistant with "Hey Google, start water level" (I'm afraid this has to be done) and then: "Can I go jogging today?" Then I get the answer: "Jogging is possible, the water level is xy centimetres. Measured at the umpteenth etc.". The whole thing was done in a few hours, which was a positive surprise for the tools used and the fact that I had previously only dealt with the Google Assistant from the user's point of view.
Here is a short Youtube video showing the result:
In the meantime, I have improved a few little things that have improved performance and recognition quality:
I would like to be able to ask my mobile phone or Google Assistant (also Google Home) directly whether I can actually go jogging or not. Decisive for this is actually only the water level of the river nearby. Sure - a quick look at it would be enough, but my primary concern is the fiddly work and the question of whether I get this task done with the means of modern digitalization.
In this article I would like to give an overview of what can be implemented quickly and easily with "enterprise" tools such as Rancher2, Kubernetes, Docker, DialogFlow and OCR, even in a small leisure setting. It should not be seen as a step-by-step guide to recreate something similar. That would go beyond the scope of this article and there is very extensive documentation on the net for all topics listed below.
After a short search in the net I found what I was looking for: An official website publishes the water level at 15-minute intervals at a monitoring station just a few kilometres away. Besides water level graphics, there is fortunately also a pure numerical table, which is only available as an image file.
After further research on the topic and the previous knowledge from the daily work with rancher, cubernetes and docker I finally came up with the following list of needed tools and started with the implementation:
A script that finds out the current water level and can be used to decide whether you can go jogging or not:
The script - the olive green deposited variables I pass from the Kubernetes environment.
A Go script of my colleague Matthias, which provides a webserver and executes a shell command defined via environment variable during a GET-call and displays the result. So here simply a "cat /mnt/pegelstand/pegelstand.json". This way I save a nginx or apache. The script is already available as binary in a docker. However, it should not be executed as a cronjob, but as a constantly available web server service.
I already have some Kubernetes clusters managed by Rancher2 available. So it is obvious to deploy the two above mentioned dockers on one of these clusters: The first one as cronjob, which is executed every 15 minutes and the second one as normal deployment. Keeping cronjobs and normal services in the same pod is not provided by Kubernetes - so I can't use an ephemeral emptyDir as volume, but have to use a normal directory from the host as shared volume.
After this was running I created a suitable Ingress under Rancher2 to allow external access to the JSON file. This includes the installation of the Certbot-Kubernetes-Charts to get letsencrypt-TLS certificates.
Screenshot of the project in Rancher2 that controls the Kubernetes cluster.
This was the part of the solution I knew least or not at all - so it's high time to learn about it: During my research about GoogleAssistant integration I stumbled over and over again over "api.io", which is now called "DialogFlow". The company was bought up by Google, is now part of the group, is very deeply interwoven with Google's API Console and is a kind of construction kit to model dialogue processes between the user and Google Assistant.
After logging in to DialogFlow, which as far as I could see is done exclusively through the Google account, you directly land in a well structured interface where you can create your first dialog.
From this point on there are numerous entry and exit points between the DialogFlow interface and the Google Cloud or Google API Console and the Assistant simulator. I haven't got deep enough into the system yet to be able to assess whether I could have realized the desired solution with Google onboard tools without DialogFlow, but it simplified the process considerably the first time around - at least that's how it seems to me at the moment.
The result is that you first have to get the Google Assistant to enter the right dialog - just like starting an app. Only then can you ask concrete questions, and you can influence the answers. My aim was to have my own answer read out of the JSON provided on the net. By adding a fulfillment object to my dialog, to which I can assign my JSON-file as webhook-URL, the whole thing went as desired.
This is what it looks like on DialogFlow.
It works! \o/ I can now address my Google Assistant with "Hey Google, start water level" (I'm afraid this has to be done) and then: "Can I go jogging today?" Then I get the answer: "Jogging is possible, the water level is xy centimetres. Measured at the umpteenth etc.". The whole thing was done in a few hours, which was a positive surprise for the tools used and the fact that I had previously only dealt with the Google Assistant from the user's point of view.
Here is a short Youtube video showing the result:
In the meantime, I have improved a few little things that have improved performance and recognition quality: