Beiträge von ggilles

  • 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.

  • KVS Robustness

    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:

    Code
    $ 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.

    * 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:

    https://git.grandou.net/gilles/shelly_…ch/main/pool.js

    * 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 ;)

  • Script randomly killed on Shelly Plus 1PM

    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 !

  • Script randomly killed on Shelly Plus 1PM

    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.