The original reason was to be able to water the garden remotely and conveniently, even when you're not at home. The storage and display of the last watering should support the user.

In the meantime I have dealt with the Shelly Plus devices and their original firmware. These devices contain an ESP 32, which offers much more programming and application potential compared to the ESP 8266. You can use the Shelly Cloud and the local network communication via MQTT in parallel. Application-specific behaviors can be implemented using scripts. I have implemented three virtual devices for time-controlled switching, as is appropriate for - also remote-controlled - garden irrigation - switch, mono and timer. In principle, these virtual devices can be distributed across different hardware.

Brief description of the virtual devices (VD)

Each of the following three VD is implemented by a JavaScript file that is set to "Enable" via the Shelly web interface and is therefore loaded and executed when Shelly is restarted.

• switch is a message-controlled switch that remembers the last switch-on time and date and, after switching off, communicates this time and the switch-on duration. It does this regardless of the trigger of the shift. I use three optional sources for triggering - a button, MQTT messages and Amazon Echo (Alexa). switch sends both the switch-on and switch-off events via message.
• mono (from monoflop) is a settable timer which, upon receipt of a "switched on" message (from switch), initializes a remaining duration countdown counter with the set duration. After each period, e.g. 1 minute, it counts down the remaining time by 1 and reports this remaining time. If the remaining duration is 0, it sends a message that is subscribed to by switch and triggers the latter to switch off. When mono receives a "disabled" message (from switch), it disables itself.
• timer is used to trigger at a set switching time with a set switching duration. The switching time is effective within a 24-hour period, i.e. it applies within the following 24 hours from the time this time is set. As soon as the switching time is reached, timer sends two messages. A message contains the duration, which mono receives, takes over and reports back. After the feedback, timer sends the switching message, which switch receives and then switches. If timer receives an empty switching time, it sets itself inactive and communicates its status via message.

New:

These three VD have now been redesigned and expanded. They exists as switch_n , mono_n and timer_n. The reason for this are two Shelly Pro 2, which I want to use for irrigation control. A Pro 2 has two switching outputs. The new VD can control multiple switching outputs and manage multiple data sets accordingly. With the startup (reboot) of Shelly, switch_n determines the number of switching outputs, creates a data record for each output and publishes this number via MQTT. As soon as mono_n and timer_n receive this MQTT message, they also create the corresponding number of data records. The new VD can also be used on a Shelly Plus 1 without modification. Should Allterco Robotics ever offer a 2nd generation Shelly with four switching outputs and script capability, then the three VD will probably be able to run on it without any changes.

In addition, I have implemented several switching modes in mono_n.

• 'p' (permanent): switching permanently, the switch on duration is deactivated
• 'm' (monoflop): switch temporarily, the switch on duration takes effect
• 'o' (once): the switch on duration takes effect once, then 'p' is present - probably hardly used
• number (as a string), the number acts as a multiplier for the switch on duration

In the last mode (number), the set duration is multiplied by this number when it is switched on, the result is the resulting switch on duration. A set duration of 3 minutes and mode '4' results in an operating time of 3*4=12 minutes. In the third figure (see below) the third tile of the first line (remaining) shows "12 m" instead of "3 m". I am currently using these modes with a lamp switched by Shelly Plus 1. The Shelly Plus 1 is controlled via Shelly i4 and MQTT. Depending on how long the button is pressed, a mode is selected and switched on or off. It is also possible to use the duration of a button press in seconds as the switch-on time in minutes. I have no experience with whether this would be user friendly. With a little practice, this could probably be used intuitively.

The following of the description still applies.

Usability

With the behavior of this VD, users can switch on or off ad hoc at any time, set the desired switching time and duration, deactivate the timer and also deactivate mono for a duration of 0 or leave it inactive. Both the entered switching time and the duration are processed in an error-tolerant manner. Unsuitable entries are simply ignored. The switching time can also be entered in short form, such as 9 -> 09:00, :5 -> 00:05.

Additional local time information service

The Shelly Plus firmware does not currently offer date tracking. In order to also deliver the current date at the notified switch-on time, I have created a small shell script on my "smartcenter", a Raspberry Pi 4 with Linux, which, when an MQTT message is received, displays the current time with the current date - and if necessary also the year - via MQTT publishing. This script is automatically started as a service. The received message requires a character string in JSON format, which among other things contains the formatting of the time information to be sent. This service can be used very flexibly.

Frontends, user machine interface

I like to use the Android app "mqtt dash" as a front end, which also works without any problems on old smartphones. Alternatively, in principle, any app that allows the configuration of MQTT messages can be used. Also e.g. Node-RED or openHAB are suitable, probably also FHEM, ioBroker, ...

Resiliency

Since the three VD communicate with each other via MQTT, this group no longer functions as such if the MQTT broker fails or there is a network failure. I have considered and documented this fact. I am working on the appropriate and implementable internal behavior for such cases. For this purpose, two status changes (connected and disconnected) are available in the script language, for which suitable event handlers are to be created. So far I have implemented the following behaviors in case of MQTT failure (probably it will remain so).

• switch : In the case of disconnected, the system is switched off, the switch-on time is calculated and the message to be sent later is saved in JSON format, including an error message. When connected, the saved message is sent.
• mono : When disconnected, the mono timer is ended. When connected, the current state of mono is sent. These are the set duration, the remaining duration (here: 0) and whether mono is running (here: false).
• timer : With disconnected, the start time is deleted if timer has already activated the switch-on via message. Otherwise the switch-on time is retained. With connected, the current state of timer is sent as a message.

Applications

So far I have focused on irrigation in the garden as an application. I will also reinstall this with Shelly Pro 2. The Shelly 1 with Tasmota will give way to these new Shelly with original firmware, although the old Shelly with Tasmota and stuffed rules have served very well. In addition to the script options of the new Shelly Pro 2, I am convinced by the LAN connections and the simple use of the cloud as well as Amazon Echo devices for voice control in addition to local MQTT communication. If necessary, the cloud connection can be deactivated very quickly and easily and only MQTT can be used.

Shelly 1 Plus devices can also be installed with the VD described above to switch any devices, such as lights. You don't have to use all the options of this VD if you don't need some. To disable the switch on duration, you can simply set the duration to 0. This also applies to the duration related to the timer. Then after switching on, if necessary at the set time, it is switched on and not switched off automatically after the duration has expired. Occasionally I want to implement a random control based on mono for lighting. This can be used when you are away from home.

Screenshots

From left to right, from top to bottom on smartphones: The Script Editor in the web browser, set and displayed in MQTT Dash ... before switching on, after switching on, after switching off