Announcement

Collapse
No announcement yet.

Dropping Z-wave over MQTT and Shelly

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #46
    I retyped my topic in the rule and now get proper topic and payload separation. Don't know why.

    The one second rule may be overloading it. For testing change the interval to something like 5 seconds. ON rules#timer=1 DO backlog ruletimer1 5;

    I would expect the Shelly firmware to be better able to handle the higher rates as it does not have all the features of Tasmota. These features are a tradeoff of capability vs. realtime performance.

    Comment


      #47
      I don't want to trouble you with this specific device. Perhaps other devices will allow for less than 10sec interval reporting or too pool it as we tried without success on this device.

      By the way. What device would you recommend for Door/Windows sensor and motion detection. How does the batter powered devices go along with MQTT?

      My goal is to completely replace Z-wave eventually.

      Thank you

      Br.
      Dali

      Comment


        #48
        The one second rule may be overloading it. For testing change the interval to something like 5 seconds. ON rules#timer=1 DO backlog ruletimer1 5;
        Tried. It's the same.

        But this one works great
        Rule1 ON Energy#Power DO publish 150-Plug/tele/SENSOR {"ENERGY":{"Power":%value%}} ENDON
        It reports 10 intervals per second plus 3 other lines along.

        Code:
        25/10/2020 22:43:53 192204617 | ActoOnMessageForTrigger Topic 150-Plug/tele/SENSOR,Payload={"ENERGY":{"Power":0}}
        25/10/2020 22:43:53 192204727 | Update Accepted 219 to 0 StatusType=2 Payload= 0 RegExValue=0
        25/10/2020 22:43:53 192204729 | Updating Device from 0 PayloadNumeric=True
        25/10/2020 22:43:53 192204729 | ManageNewMessage 150-Plug/tele/SENSOR
        25/10/2020 22:43:53 192204729 | ActoOnMessageForTrigger Topic 150-Plug/tele/SENSOR,Payload={"ENERGY":{"Power":0}}
        25/10/2020 22:43:53 192204827 | Update Accepted 219 to 0 StatusType=2 Payload= 0 RegExValue=0
        25/10/2020 22:43:54 192204828 | Updating Device from 0 PayloadNumeric=True
        25/10/2020 22:43:54 192204829 | ManageNewMessage 150-Plug/tele/SENSOR
        25/10/2020 22:43:54 192204829 | ActoOnMessageForTrigger Topic 150-Plug/tele/SENSOR,Payload={"ENERGY":{"Power":0}}
        25/10/2020 22:43:54 192204928 | Update Accepted 219 to 0 StatusType=2 Payload= 0 RegExValue=0
        25/10/2020 22:43:54 192204929 | Updating Device from 0 PayloadNumeric=True
        25/10/2020 22:43:54 192204930 | ManageNewMessage 150-Plug/tele/SENSOR
        25/10/2020 22:43:54 192204930 | ActoOnMessageForTrigger Topic 150-Plug/tele/SENSOR,Payload={"ENERGY":{"Power":0}}
        25/10/2020 22:43:54 192205027 | Update Accepted 219 to 0 StatusType=2 Payload= 0 RegExValue=0
        25/10/2020 22:43:54 192205028 | Updating Device from 0 PayloadNumeric=True
        25/10/2020 22:43:54 192205029 | ManageNewMessage 150-Plug/tele/SENSOR
        25/10/2020 22:43:54 192205029 | ActoOnMessageForTrigger Topic 150-Plug/tele/SENSOR,Payload={"ENERGY":{"Power":0}}
        25/10/2020 22:43:54 192205126 | Update Accepted 219 to 0 StatusType=2 Payload= 0 RegExValue=0
        25/10/2020 22:43:54 192205128 | Updating Device from 0 PayloadNumeric=True
        25/10/2020 22:43:54 192205128 | ManageNewMessage 150-Plug/tele/SENSOR
        25/10/2020 22:43:54 192205128 | ActoOnMessageForTrigger Topic 150-Plug/tele/SENSOR,Payload={"ENERGY":{"Power":0}}
        25/10/2020 22:43:54 192205227 | Update Accepted 219 to 0 StatusType=2 Payload= 0 RegExValue=0
        25/10/2020 22:43:54 192205228 | Updating Device from 0 PayloadNumeric=True
        25/10/2020 22:43:54 192205229 | ManageNewMessage 150-Plug/tele/SENSOR
        25/10/2020 22:43:54 192205229 | ActoOnMessageForTrigger Topic 150-Plug/tele/SENSOR,Payload={"ENERGY":{"Power":0}}
        25/10/2020 22:43:54 192205327 | Update Accepted 219 to 0 StatusType=2 Payload= 0 RegExValue=0
        25/10/2020 22:43:54 192205329 | Updating Device from 0 PayloadNumeric=True
        25/10/2020 22:43:54 192205330 | ManageNewMessage 150-Plug/tele/SENSOR
        25/10/2020 22:43:54 192205330 | ActoOnMessageForTrigger Topic 150-Plug/tele/SENSOR,Payload={"ENERGY":{"Power":0}}
        25/10/2020 22:43:54 192205428 | Update Accepted 219 to 0 StatusType=2 Payload= 0 RegExValue=0
        25/10/2020 22:43:54 192205430 | Updating Device from 0 PayloadNumeric=True
        25/10/2020 22:43:54 192205430 | ManageNewMessage 150-Plug/tele/SENSOR
        25/10/2020 22:43:54 192205430 | ActoOnMessageForTrigger Topic 150-Plug/tele/SENSOR,Payload={"ENERGY":{"Power":0}}
        25/10/2020 22:43:54 192205529 | Update Accepted 219 to 0 StatusType=2 Payload= 0 RegExValue=0
        25/10/2020 22:43:54 192205531 | Updating Device from 0 PayloadNumeric=True
        25/10/2020 22:43:54 192205531 | ManageNewMessage 150-Plug/tele/SENSOR
        25/10/2020 22:43:54 192205531 | ActoOnMessageForTrigger Topic 150-Plug/tele/SENSOR,Payload={"ENERGY":{"Power":0}}
        25/10/2020 22:43:54 192205629 | Update Accepted 219 to 0 StatusType=2 Payload= 0 RegExValue=0
        25/10/2020 22:43:54 192205637 | Updating Device from 0 PayloadNumeric=True
        25/10/2020 22:43:54 192205638 | ManageNewMessage 150-Plug/tele/SENSOR
        25/10/2020 22:43:54 192205638 | ActoOnMessageForTrigger Topic 150-Plug/tele/SENSOR,Payload={"ENERGY":{"Power":0}}
        25/10/2020 22:43:54 192205729 | Update Accepted 219 to 0 StatusType=2 Payload= 0 RegExValue=0
        25/10/2020 22:43:54 192205730 | Updating Device from 0 PayloadNumeric=True
        25/10/2020 22:43:54 192205731 | ManageNewMessage 150-Plug/tele/SENSOR
        25/10/2020 22:43:54 192205731 | ActoOnMessageForTrigger Topic 150-Plug/tele/SENSOR,Payload={"ENERGY":{"Power":0}}
        25/10/2020 22:43:55 192205832 | Update Accepted 219 to 0 StatusType=2 Payload= 0 RegExValue=0
        25/10/2020 22:43:55 192205833 | Updating Device from 0 PayloadNumeric=True
        25/10/2020 22:43:55 192205834 | ManageNewMessage 150-Plug/tele/SENSOR
        25/10/2020 22:43:55 192205834 | ActoOnMessageForTrigger Topic 150-Plug/tele/SENSOR,Payload={"ENERGY":{"Power":0}}
        25/10/2020 22:43:55 192205930 | Update Accepted 219 to 0 StatusType=2 Payload= 0 RegExValue=0
        25/10/2020 22:43:55 192205932 | Updating Device from 0 PayloadNumeric=True
        25/10/2020 22:43:55 192205932 | ManageNewMessage 150-Plug/tele/SENSOR
        25/10/2020 22:43:55 192205932 | ActoOnMessageForTrigger Topic 150-Plug/tele/SENSOR,Payload={"ENERGY":{"Power":0}}
        25/10/2020 22:43:55 192206032 | Update Accepted 219 to 0 StatusType=2 Payload= 0 RegExValue=0
        25/10/2020 22:43:55 192206033 | Updating Device from 0 PayloadNumeric=True
        25/10/2020 22:43:55 192206034 | ManageNewMessage 150-Plug/tele/SENSOR
        25/10/2020 22:43:55 192206034 | ActoOnMessageForTrigger Topic 150-Plug/tele/SENSOR,Payload={"ENERGY":{"Power":0}}
        25/10/2020 22:43:55 192206130 | Update Accepted 219 to 0 StatusType=2 Payload= 0 RegExValue=0
        25/10/2020 22:43:55 192206131 | Updating Device from 0 PayloadNumeric=True
        25/10/2020 22:43:55 192206132 | ManageNewMessage 150-Plug/tele/SENSOR
        25/10/2020 22:43:55 192206132 | ActoOnMessageForTrigger Topic 150-Plug/tele/SENSOR,Payload={"ENERGY":{"Power":0}}
        25/10/2020 22:43:55 192206230 | Update Accepted 219 to 0 StatusType=2 Payload= 0 RegExValue=0
        25/10/2020 22:43:55 192206231 | Updating Device from 0 PayloadNumeric=True
        25/10/2020 22:43:55 192206232 | ManageNewMessage 150-Plug/tele/SENSOR
        25/10/2020 22:43:55 192206232 | ActoOnMessageForTrigger Topic 150-Plug/tele/SENSOR,Payload={"ENERGY":{"Power":0}}
        25/10/2020 22:43:55 192206330 | Update Accepted 219 to 0 StatusType=2 Payload= 0 RegExValue=0
        25/10/2020 22:43:55 192206332 | Updating Device from 0 PayloadNumeric=True
        25/10/2020 22:43:55 192206332 | ManageNewMessage 150-Plug/tele/SENSOR
        Br,
        Dali

        Comment


          #49
          Probably even better for you. Look as Statistics tab in mcsMQTT to get an idea of how the plugin is keeping up. You can also check the E column checkbox for this topic to reduce CPU burden on the HS computer. Suggest turning off debug when you are not investigating issues as the debug file could grow pretty big at these rates.

          Comment


            #50
            Thank you for suggestions. It's a testing machine. No worries.

            I've googled and there seems no way to set Teleperiod lower than 10sec for any Tasmota device out there. I guess there must be a reason for that, I also read that modern brokers can handle hundreds of messages per second without a problem as it was my thinking from the start. So this doesn't quite match, If modern brokers can handle that much, why would one limit for 10sec minimum. What is someone has only a few devices and wants an instant response? Doesn't make much sense to me.

            We tried to pool the device without a success.

            If possible one could pool the device when needed or ser a loop event to get desired interval.

            Or to hack it with a rule to send if faster. I think you very very close.
            Rule1 ON Energy#Power DO publish 150-Plug/tele/SENSOR {"ENERGY":{"Power":%value%}} ENDON
            This one actually works but with 10 intervals and 3 additional lines.

            Br,
            Dali
            ​​​​​​​





            Comment


              #51
              The MQTT broker has a very specific task to perform and can do it quite efficiently. Tasmota is designed to handle everything that is thrown at it so its logic needs to be more generalized and cannot handle the high rates than can be achieved when only doing a single specific thing. The ESP32 version of Tasmota will be able to handle more, but ESP32 devices in the commercial marketplace have not yet arrived. With respect to Shelly, I suspect it will handle higher rates than Tasmota because it only needs to deal with the specific device it is controlling and the the myriad of things the the user community dreams up.

              It is hard to assess what logic and overhead exist with managing a rule timer. The only reason I use the rule timer is to reduce the MQTT reporting burden and this was primarily because of the traffic that needs to be analyzed by mcsMQTT. If mcsMQTT can handle it, your network can handle it, and Tasmota can handle reporting via MQTT every time it takes an energy sample, then this is a good solution.

              Comment


                #52
                I think I'm onto something about pooling the device.



                If I enter STATUS 8 in the console I get the line I need.

                Code:
                25/10/2020 23:53:22 196374794 | ManageNewMessage 150-Plug/stat/STATUS8
                25/10/2020 23:53:22 196374794 | ActoOnMessageForTrigger Topic 150-Plug/stat/STATUS8,Payload={"StatusSNS":{"Time":"2020-10-25T23:53:21","ENERGY":{"TotalStartTime":"2020-10-21T20:12:06","Total":0.374,"Yesterday":0.006,"Today":0.069," Power":0,"ApparentPower":0,"ReactivePower":0,"Factor":0.00," Voltage":0,"Current":0.000}}}
                But when I try to trigger it from HS Event

                Click image for larger version

Name:	stat.jpg
Views:	32
Size:	35.9 KB
ID:	1428651

                I get this.

                Code:
                25/10/2020 23:56:10 196542200 | Handle Action TANumber 0 input of 150-Plug/stat/STATUS 8=
                25/10/2020 23:56:10 196542200 | Handle Action Topic 150-Plug/stat/STATUS 8
                25/10/2020 23:56:10 196542200 | Handle Action Topic=Payload 150-Plug/stat/STATUS 8=

                So when I enter console it's ManageNewMessage, but when I trigger it with HS Event is Handle Action Topic.

                Does that means anything to you?

                Br,
                Dali





                Comment


                  #53
                  I can even trigger it directly from the browser:

                  http://192.168.6.150/cm?cmnd=Status%208

                  Br.
                  Dali

                  Comment


                    #54
                    Got it working my friend !!!

                    Using a rule

                    Click image for larger version

Name:	stat2.jpg
Views:	27
Size:	26.4 KB
ID:	1428660

                    I'm sure you will let me know how to do it directly from Send Mqtt Message or Publist as I couldn't figure it out.

                    Thank you

                    Br,
                    Dali

                    Comment


                      #55
                      This tells me that STATUS8 via MQTT command does the some nothing as SENSOR via MQTT. The HandleAction lines just confirm the message is being sent. Seems to me Tasmota should respond the same if the source is console, http, or mqtt. Could be reported as a bug and if it happens not to be then the correct mechanism would be shown.

                      Since Tasmota does have an http interface you can use it as you did. Is it overall more efficient than just transmitting via MQTT every time the energy sample is taken by Tasmota? It elevates the logic to HS to initiate a poll rather than it being initiated by Tasmota when a sample is taken.

                      Comment


                        #56
                        Hi Kdiamond ! Glad to see you've made the jump to WiFI devices and Tasmota. Sorry for jumping in so late, but wrt the power reporting frequency, you might want to look into the PowerDelta setting. https://tasmota.github.io/docs/Commands/#powerdelta

                        With PowerDelta you can set relative or absolute value change on which a MQTT message should be send. Never used it, but I believe that will nicely fit your need without flooding your network or overloading HS4.

                        And I told you it would be a steep learning curve so I hope you enjoy the ride!
                        stefxx

                        Comment

                        Working...
                        X