New MQTT topics constructive criticism and product safety

  • Hello, I've been a shelly user for a few years now and I love your products! Keep up the good work!

    I've recently purchased a bunch of shelly 2pm plus to automate all the rollers in my new house and, for the most part, everything went smoothly.

    I'm using Node-RED to interact via MQTT with the shellies and it has been quite easy to adapt my code to the new topic structure.

    However, there's one change that I think makes the product worse, at least from a safety standpoint.

    On old v1 devices, alarm statuses were ALWAYS published via MQTT, even when there was no actual alarm; see following example, with interesting messages highlited in red. This was GOOD, because amateur programmers like me could very easily write code for alarms (if overtemperature is false, everything is ok, if it's everything else, send an email, play an alarm sound, send a telegram messages, etc.).

    shellyswitch25-0123456789AB

    roller (6 topics, 7405 messages)
    relay (2 topics, 2957 messages)
    input (2 topics, 2948 messages)
    temperature = 37.90
    temperature_f = 100.22
    overtemperature = 0
    temperature_status = Normal
    voltage = 221.26
    online = true
    announce = {"id":"shellyswitch25-0123456789AB","model":"SHSW-25","mac":"0123456789AB","ip":"192.168.178.181","new_fw":false,"fw_ver":"20230503-095750/v1.13.0-g9aed950","mode":"roller"}
    info = {"wifi_sta":{"connected":true,"ssid":"myfakessid","ip":"192.168.111.123","rssi":-58},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":true},"time":"11:32","unixtime":1683883944,"serial":7,"has_update":false,"mac":"0123456789AB","cfg_changed_cnt":0,"actions_stats":{"skipped":0},"rollers":[{"state":"stop","source":"input","power":0,"is_valid":true,"safety_switch":false,"overtemperature":false,"stop_reason":"normal","last_direction":"open","current_pos":100,"calibrating":false,"positioning":false}],"meters":[{"power":0,"overpower":0,"is_valid":true,"timestamp":1683891144,"counters":[0,0,0],"total":171},{"power":0,"overpower":0,"is_valid":true,"timestamp":1683891144,"counters":[0,0,0],"total":0}],"inputs":[{"input":0,"event":"","event_cnt":0},{"input":0,"event":"","event_cnt":0}],"temperature":39.37,"overtemperature":false,"tmp":{"tC":39.37,"tF":102.86,"is_valid":true},"temperature_status":"Normal","update":{"status":"idle","has_update":false,"new_version":"20230503-095750/v1.13.0-g9aed950","old_version":"20230503-095750/v1.13.0-g9aed950"},"ram_total":50720,"ram_free":37536,"fs_size":233681,"fs_free":144827,"voltage":220.78,"uptime":43957}

    With the new v2 API, alarms only get published when there's an actual alarm (see https://shelly-api-docs.shelly.cloud/gen2/Component…es/Cover#status); how are we supposed to test it? It's very hard to write correct code if we do not have a way to test it, and, as much as I like and trust your products, I REALLY REALLY want to know if there's something wrong with one of my shellies, before one of them catches fire.

    Please update the firmware to always publish alarms, or, at the very least, add a section in the GUI to allow programmers to generate fake alarms so we can test for them.

    Thank you for reading this far!

    Best regards

    gsrbiker

    Einmal editiert, zuletzt von gsrbiker (14. Mai 2023 um 17:15)