Beiträge von ggilles

I've added KVS support to my script (now hosted here: https://git.grandou.net/gilles/shelly_pool).

Unfortunately there I've experienced other issues with KVS:
KVS Robustness

Zitat

Ever tried to delay the request from the storage after start? What happens if you restart your script a second time?

nope, once it's gone it permanent, restarting the script changes nothing. And KVS looks like to be ready at startup, because it's not really empty: it's pre-poluated with default content (script-library entry for instance), it's just that all user entries have disappeared.

I was wondering if, in my script, two parallel KVS.Get calls could be an issue. but:
* it looks like to work in normal case

* the 1st fail I've seen (with the typo error) was created from a test script with only call.

Hello,

Running on a Shelly Pro 1PM with firmware 1.11 (20220830-131534/0.11.0-gfa1bc37), I gave KVS a try.

I have noticed several times, where all KVS variables were lost:

$ curl -s 'http://$SHELLY/rpc/KVS.List' | jq .
{
  "keys": {
    "scripts-library": {
      "etag": "64qBCCQKaC"
    }
  },
  "rev": 35
}

I have identified two cases where it happens:

* The 1st one, when doing some tests I've made a syntax error inside the callback function of a KVS.Get call. The script has crashed (that's normal) but all the KVS storage was voided immediately after. only the rev field was kept.

Shelly.call (
   "KVS.Get"
   { key: "pool_temp" },
   function (result) {
      if (result) {
         print("[TEST] KVS Get: ", JSON.stringify(resul.value)); // typo
       }
      else {
         print("[TEST] KVS Get: (null)");
      }
   }
);

* The 2nd one has happened this night, the house has suffered a power outage during a storm. Once Shelly was back to life, all KVS storage was empty.

If it can help, here the script I'm currently running:

* 2 KVS.Get calls are performed on startup

* 1 KVS.Set upon a new temperature change from a mqtt message, a few times per day

* 2 KVS Set after midnight

Thanks for any hint to improve reliabilty

Zitat

Hi ggilles ,

I modify your script for my usage here, thank you very much:

https://github.com/sylvaing/shelly-pool-pump

I wait stable version of firmware to use KVS

Excellent !
Thanks for sharing, the HA integration looks great !

let my_int = 2;
let my_float = 3.14;
let my_string = "values: " + JSON.stringify(my_int) + ", " + JSON.stringify(my_float);

will produces the string "values: 2, 3.14"

I've just seen that there's a beta update available for my Shelly Plus 1PM: 0.10.2-beta3.
It it the next release you were talking about @mircho.mirev ?
Is key-value storage available with this update ? if yes, what is the API ?

Thanks for the feedback !

Thanks for your explanation about stopped scripts upon reboot. The observed behavior makes a lot more sense now.

Still, I'm not sure it could come from an electrical problem: the script aborts and reboots don't happen at times the pump is started or stopped. Anyway I might have some power consumption variation leading to unwanted spikes. I've a few spare RC snubber, you're right I should try to add one. just in case

So at least with the next version if other scripts are not impacted, that mean I could re-enable the pool script on a regular basis from another script

Plus with the support of permanent storage, that would mean that the script would be completely immune from kills/restarts !

For the exact root cause of kills, I still think it's linked to regular wifi loss and may be a bad recovery of mqtt agent. tough It's difficult to investigate as loosing wifi and/or reboot means loosing logs too

If you're looking for any beta testing for the next update I'm you man !

Here is in attachment (renamed as .txt to bypass upload restriction)

It works quite well, modulo the script being killed several times per day and/or the device being rebooted without restarting the script

Sure ! I'll put it on a git this evening

Hi,

I'm using a Shelly Plus1PM to automate my pool pump

I've created a script which performs the following actions:
- listening a specific MQTT topic to retrieve the current water temperature

- keeping the max temperature of the day, and for the previous day.

- computing the needed filtering time, based on the current max temp

- defining the schedule (start/stop time, in the morning and in the afternoon)

- updating the Shelly On/Off schedule for the day.

- filtering updates to max 1 per 10 minutes

- filtering temperature update for 10 minutes after the pump has started (my sensor is located in the skimmer, so I often see a several °C spike when water starts to flow again).

It's working perfectly well ! Shelly scripting is really a big plus. It avoids the automation to be dependent from other components: if I loose my home assistant instance, if my server burns in fire, if the internet connection is lost, ... my pumps will still continue to operate (on a fixed schedule).

But... there's a caveat somewhere: the script is randomly killed several times a day and the only way I found to workaround is to send automated Script.Start command with API, which defeats the autonomous advantage above

I've tried running a 2nd script to perform the same thing locally. It works... until this 2nd script gets killed too...

Sometimes, not only the script is killed but the device is reset as well, and it looks like the script is not automatically restarted (even though the Enable Flag is set).

There is no clear message in the logs. It does not happen when the pump is started/stopped, so it's unlikely to be a power issue.

The only pattern I see is that the script is often killed when the WiFi is disconnected. My Shelly is located in a concrete shelter quite far the house and the WiFi reception is quite flaky and the devices loses connections several times per day (I might upgrade it to a Shelly PRO1PM with Ethernet and CPL when it will be available).

I have a 2nd Shelly Plus1PM I use for tests. It runs the same script, receives the same MQTT messages. the only difference is that there's nothing plugged on the relay and it is located on my desk with excellent WiFi coverage. The script has been running flawlessly without having been killed for more than 1 week.

Did anybody experience the same behavior ? Is it a known issue ? Is there any known solution ?

As a side band note, it would be cool to have local storage for script, to not lose max temp when script is restarted

Thanks,

Gilles.