Announcement

Collapse
No announcement yet.

(Very) slow start and shutdown

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

    (Very) slow start and shutdown

    I noticed that starting up and closing down the plugin takes longer every time. I not have about 80 Tasmota devices, planning to add 10 to 20 more. The database contains nearly 15.500 entries, including almost 600 accept entries. At startup, PopulateMqttReceiveDictionary is taking most of the time. First, it reads all the accept topics, which takes around 25 seconds. After that, in the background, it reads all 15.500 entries, which takes about 210 seconds. In those 4 minutes in total, it seems that the plugin does not accept nor send any topics.

    I understand that all accept entries must be processed before you accept any received topic, but is it really necessary to wait to read ALL entries before the plugin becomes operational? Or is there anything that can be done to speed up this process?

    I haven't looked at closing the plugin yet.

    Thanks!
    stefxx

    #2
    This was very recently changed from a two-pass initialization to a single pass due to issue with devices in the database were not in HS so needed to be created. I look at this again for a solution that still allows two-pass initialization.

    Shutdown time is a function of the number of topics that had changes during the session. This part did not change recently to my knowledge.

    Comment


      #3
      I restored logic to use a two pass initialization at http://mcsSprinklers.com/HSPI_mcsMQTT_5_9_5_4.zip. This also contains going back to my original method to deal with period vs. comma so be on the lookout if you have expressions that may involve these characters.

      Comment


        #4
        Hi Michael, thanks!

        Why did you revert the comma/period method? Do I need to replace "\." with "," again?
        stefxx

        Comment


          #5
          The method that you suggested and had been implemented but did not work for a Canadian user. It caused further issues when using expressions where my parser sees the comma and things the expression is a string rather than numeric. At least with the plugin doing explicit management of the decimal character I know what is going to happen before and after expressions.

          You should not need to change anything on your end. If a 12.34 is seen in the payload then the plugin should recognize this as 12,34 as it stores into HS DeviceValue. If it does not then we will need to figure out why. If you use the payload in an expression it should already be in the expected numeric format.

          Comment


            #6
            Hi, thanks, I understand. When I receive a value with decimals (like 12.34) the value that gets stored into HS4 is 1234...
            stefxx

            Comment

            Working...
            X