Announcement

Collapse
No announcement yet.

Version 3.4.x.x

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

  • Version 3.4.x.x

    Version 3.4.0.0 was placed in the updater and includes the general additional of charting of HS device value history using the same mechanism that has been provided for MQTT payload charting.

    A new "D"evice column has been added to the Association tab, Chart tab item selectors now accept either topic or device reference, General tab adds a row to save all or only items checked in "D" column, and the LastDate now has a hyperlink to pop up a chart for Device history just like the Payload hyperlink does it for Payload history.

    For the case of the mcsMQTT rate and accum devices, the checkbox for the base device should be used and all the devices associated with this base device will be save to the database for charting.

    The association tab columns have been rearranged to the right-most two (D and LastDate) provide the charting control for the HS devices. Next to these (H and Payload) are the charting control for Payloads.

    Charts on demand are done in the same way for Device Values as was done for MQTT Payloads with the only difference being that a number (Device Reference) rather than the MQTT Topic is the parameter to identify the item being requested.

  • #2
    Updated to V.3.4.0.0.

    Thank you Michael.

    Tinkering here with the Lightning Rate.

    Click image for larger version

Name:	image_68904.jpg
Views:	184
Size:	41.7 KB
ID:	1196832

    The association tab columns have been rearranged to the right-most two (D and LastDate) provide the charting control for the HS devices. Next to these (H and Payload) are the charting control for Payloads.Charts on demand are done in the same way for Device Values as was done for MQTT Payloads with the only difference being that a number (Device Reference) rather than the MQTT Topic is the parameter to identify the item being requested.

    Works great Michael.
    Click image for larger version

Name:	image_68905.jpg
Views:	182
Size:	26.4 KB
ID:	1196833

    More data over the last few hours show an approaching storm.
    Click image for larger version

Name:	image_68906.jpg
Views:	180
Size:	32.6 KB
ID:	1196834

    Click image for larger version

Name:	image_68910.jpg
Views:	175
Size:	142.0 KB
ID:	1196836
    Attached Files
    Last edited by Pete; September 2nd, 2018, 02:27 PM.
    - Pete

    Auto mator
    Homeseer 3 Pro - 3.0.0.534 (Linux) - Ubuntu 18.04/W7e 64 bit Intel Haswell CPU - Mono 6.4X
    Homeseer Zee2 (Lite) - 3.0.0.534 (Linux) - Ubuntu 18.04/W7e - CherryTrail x5-Z8350 BeeLink 4Gb BT3 Pro - Mono 6.4X

    X10, UPB, Zigbee, ZWave and Wifi MQTT automation.

    Comment


    • #3
      Afternoon and sunny...

      Click image for larger version

Name:	image_68920.jpg
Views:	168
Size:	175.4 KB
ID:	1196845
      Last edited by Pete; September 2nd, 2018, 02:27 PM.
      - Pete

      Auto mator
      Homeseer 3 Pro - 3.0.0.534 (Linux) - Ubuntu 18.04/W7e 64 bit Intel Haswell CPU - Mono 6.4X
      Homeseer Zee2 (Lite) - 3.0.0.534 (Linux) - Ubuntu 18.04/W7e - CherryTrail x5-Z8350 BeeLink 4Gb BT3 Pro - Mono 6.4X

      X10, UPB, Zigbee, ZWave and Wifi MQTT automation.

      Comment


      • #4
        Looks like the data does not lie.

        Comment


        • #5
          Version 3.4.1.0 adds a Delete button on the first Table/Row of the Edit tab. It can be used to remove all traces of obsolete topics and devices that may have been created when experimenting. When used it removes subscribed topic and devices/references from the mcsMQTT database and from HS3.

          The easiest way to get to the Edit is from Association tab by clicking on the Sequence or Ref row links. If the row had not been previously Accepted then a new HS device will be created, but when the Delete button is used it will be removed.

          Comment


          • #6
            Updated to V.3.4.1.0

            Thank you Michael.

            This morning (off on a bit of a lightning tangent) playing with the AS3935 Lightning sensor connected to another RPi. It works but really isn't sensitive enough. I was going to modify the python script to make it speak Mosquitto but not sure if it is worth it. Be better to battery power it outside and utilize an Arduino maybe. Thunderstorm this morning with much lightning and not seeing much with the sensor versus the Hobby Boards Lightning sensor (in the attic).

            Click image for larger version

Name:	image_68926.jpg
Views:	156
Size:	26.2 KB
ID:	1196849

            Googling this morning see:

            Trying to calibrate the AS3935 Lightning IC.

            Calibrating the chip has been the major issue so far. The chip has several values that need calibration to avoid false positives:
            • noise floor threshold : 0...7
            • watchdog threshold : 0...7
            • spike rejection threshold : 0...7
            • AFE gain : setIndoors..or..setOutdoors


            Good practice is to recalibrate after every setting change.

            Others report:
            • setting it too sensitive make it less sensitive to local strikes, and setting it less sensitive makes it less sensitive to remote strikes
            • grounding the chip (to mains ground) reduces the number of strikes it reports, better battery power
            Last edited by Pete; September 2nd, 2018, 02:28 PM.
            - Pete

            Auto mator
            Homeseer 3 Pro - 3.0.0.534 (Linux) - Ubuntu 18.04/W7e 64 bit Intel Haswell CPU - Mono 6.4X
            Homeseer Zee2 (Lite) - 3.0.0.534 (Linux) - Ubuntu 18.04/W7e - CherryTrail x5-Z8350 BeeLink 4Gb BT3 Pro - Mono 6.4X

            X10, UPB, Zigbee, ZWave and Wifi MQTT automation.

            Comment


            • #7
              Version 3.4.2.0 contains the new SSL implementation done by vasrc. There was considerable effort he contributed to dig into this and make it functional. Also included is a new m2mqtt.dll compile with necessary changes to make it work. This new dll is in the updater download with 3.4.2.0.

              A new section to the manual was also contributed by vasrc that fully describes the SLL considerations and the specifics of how a user can get encryption working with mcsMQTT & Mosquitto.

              For those that desire encrypted communication with MQTT then a big THANK YOU is needed to be given vasrc.

              Comment


              • #8
                Thank you vasrc and Michael.

                Updated to V3.4.2.0. No issues with updates.

                Oddest thing...this morning saw the mcsMQTT update and another plugin (WeatherXML) update on both the Homeseer 3 Pro box and Homeseer 3 lite box.

                This afternoon went to plugin manager to update and Homeseer 3 Pro was already updated and Homeseer 3 lite was not and I updated it.
                - Pete

                Auto mator
                Homeseer 3 Pro - 3.0.0.534 (Linux) - Ubuntu 18.04/W7e 64 bit Intel Haswell CPU - Mono 6.4X
                Homeseer Zee2 (Lite) - 3.0.0.534 (Linux) - Ubuntu 18.04/W7e - CherryTrail x5-Z8350 BeeLink 4Gb BT3 Pro - Mono 6.4X

                X10, UPB, Zigbee, ZWave and Wifi MQTT automation.

                Comment


                • #9
                  Just a note relating to version 3.4.2.0.

                  Very simple set up here with two Node Red OWFS brokers. One of the two brokers after a day or two disconnects. To fix it I enter the IP / port of the disconnected broker and it connects and all is well until it disconnects again. Another thing I was doing and it was working was disabling and re-enabling the mcsMQTT plugin.

                  The mcsMQTT Statistics remain online. The only way to tell here is that the variables do not change.
                  - Pete

                  Auto mator
                  Homeseer 3 Pro - 3.0.0.534 (Linux) - Ubuntu 18.04/W7e 64 bit Intel Haswell CPU - Mono 6.4X
                  Homeseer Zee2 (Lite) - 3.0.0.534 (Linux) - Ubuntu 18.04/W7e - CherryTrail x5-Z8350 BeeLink 4Gb BT3 Pro - Mono 6.4X

                  X10, UPB, Zigbee, ZWave and Wifi MQTT automation.

                  Comment


                  • #10
                    Pete, can you clarify a little. What I understand is that you have two nodes that run OWFS and one of these disconnects from MQTT broker over time. You get this node working again by reentering the IP. This is all independent of mcsMQTT.

                    You also disable mcsMQTT plugin from HS Plugin page. When you do this the mcsMQTT statistics no longer update in HS devices. This should be expected as mcsMQTT has been disabled.

                    Do I have this correct?

                    Comment


                    • #11
                      Yes.

                      one of these disconnects from MQTT broker over time

                      The Node Red (web IP:1880) shows it connected to Homeseer. Never shows disconnected.


                      Click image for larger version

Name:	image_69166.jpg
Views:	122
Size:	82.3 KB
ID:	1196997

                      I look at the Homeseer Variable list of the two nodes (temperatures and humidity) and see the last change being yesterday for example if there is an issue. Here is what I look at.

                      Click image for larger version

Name:	image_69167.jpg
Views:	121
Size:	44.3 KB
ID:	1196998

                      I either re-enter the IP of the broker not talking or disable and re enable the plugin. I see the change immediately looking at the Homeseer mcsMQTT variables list and it shows last change to current or near current time.

                      You also disable mcsMQTT plugin from HS Plugin page. When you do this the mcsMQTT statistics no longer update in HS devices. This should be expected as mcsMQTT has been disabled.

                      Yes. Only sometimes when the plugin is enabled the stats and online stats goes offline. This is concurrent to see the stats sometimes going off line without me disabling the plugin. I then disable the plugin and then enable the plugin and it goes back to on line status.

                      Click image for larger version

Name:	image_69168.jpg
Views:	120
Size:	43.4 KB
ID:	1196999
                      Last edited by Pete; September 2nd, 2018, 02:29 PM.
                      - Pete

                      Auto mator
                      Homeseer 3 Pro - 3.0.0.534 (Linux) - Ubuntu 18.04/W7e 64 bit Intel Haswell CPU - Mono 6.4X
                      Homeseer Zee2 (Lite) - 3.0.0.534 (Linux) - Ubuntu 18.04/W7e - CherryTrail x5-Z8350 BeeLink 4Gb BT3 Pro - Mono 6.4X

                      X10, UPB, Zigbee, ZWave and Wifi MQTT automation.

                      Comment


                      • #12
                        The m2mqtt.dll manages the broker connection. mcsMQTT creates an object for this dll and then in a 10 second polling loop queries it to confirm a broker connection exists. The "isConnected" status drives the Online vs. Offline status reporting. If you have a HS event setup to trigger on MQTT connection status then this event should trigger on a change of the status.

                        When "IsConnected" is false then it creates a new object to use m2mqtt.dll and then goes through the process of establishing a new session with the broker.

                        When you disable/enable or touch the broker IP or security credentials then this process is forced. What your observations are telling me is that m2mqtt.dll continues to report "IsConnected" after the broker connection has been lost so mcsMQTT does not know it needs to start a new session.

                        My original design use a callback to m2mqtt.dll asking to be informed when Connection status changes. I never say this event being raised, but was able to use the polling approach to evaluate connection with broker.

                        I suspect a bandaid could be applied. There currently exists a mcsMQTT trigger for too much time elapsed for a particular topic. The intent was to monitor reporting nodes that may not be using LWT. The plugin currently does not have any action that would reset the connection to the broker, but it could be done.

                        Continue to monitor and in particular observe the Online statistics device to confirm no messages have been received for some time. If you are publishing any Topics then try to publish when the failure exists to see if connection was lost in both directions.

                        Comment


                        • #13
                          Thank you Michael.

                          It is very random and first noticed when beta testing a couple of weeks back as I went from using or testing SSL to regular communications.

                          I would disable SSL and the connection status would remain disconnected and that was where I would enable and disable the plugin (just for testing SSL) and then it would be fine until it would randomly disconnect.

                          Then when this happened I would enter the broker IP and then it would come up again as mentioned in the next paragraph.

                          IE: the fix for me is if using broker IP 192.168.244.175 I would change it to IP 192.168.244.169 or vice versa then it connects. This is also where I see it go offline. When I change the IP then it goes back on line. I do not disable or enable the plugin when this is happening.

                          Not touching, upgrading or rebooting the two Node Red RPi's and have left them alone.

                          I am not yet publishing any topics.

                          The two Sonoff hardware and firmware modification are completed. Just finished the second Sonoff upgrade as it was stuck after I had updated the firmware to Sonoff firmware revision 1.6. It is now working just fine.

                          Next is testing the hardware in the garage.
                          - Pete

                          Auto mator
                          Homeseer 3 Pro - 3.0.0.534 (Linux) - Ubuntu 18.04/W7e 64 bit Intel Haswell CPU - Mono 6.4X
                          Homeseer Zee2 (Lite) - 3.0.0.534 (Linux) - Ubuntu 18.04/W7e - CherryTrail x5-Z8350 BeeLink 4Gb BT3 Pro - Mono 6.4X

                          X10, UPB, Zigbee, ZWave and Wifi MQTT automation.

                          Comment


                          • #14
                            Noticed this morning that the mcsMQTT plugin stopped counting / seeing the lightning sensor yesterday. Attached picture shows Node Red Values live showing the counter incrementing while mcsMQTT shows that it stopped reading the values. It is odd because it is reading other values fine from same Node.

                            Click image for larger version

Name:	image_69188.jpg
Views:	105
Size:	115.3 KB
ID:	1197018

                            Click image for larger version

Name:	image_69189.jpg
Views:	101
Size:	22.6 KB
ID:	1197019
                            Last edited by Pete; September 2nd, 2018, 02:30 PM.
                            - Pete

                            Auto mator
                            Homeseer 3 Pro - 3.0.0.534 (Linux) - Ubuntu 18.04/W7e 64 bit Intel Haswell CPU - Mono 6.4X
                            Homeseer Zee2 (Lite) - 3.0.0.534 (Linux) - Ubuntu 18.04/W7e - CherryTrail x5-Z8350 BeeLink 4Gb BT3 Pro - Mono 6.4X

                            X10, UPB, Zigbee, ZWave and Wifi MQTT automation.

                            Comment


                            • #15
                              It may be down to wireshark to see which side of the broker the communications have stopped. mcsMQTT is notified by m2mqtt.dll when a new message received on the socket. The first thing it does is update the statitics. You can look at the statistics tab or equivalent HS devices, if created, to observe. After it has decoded JSON as necessary then it updates the Association tab and HS devices. There is debug output also created, but should not need to go that route to see missing messages.

                              You could also setup a mcsMQTT timeout trigger on that topic so you get other forms of notification rather than casual observation that messages have stopped.

                              Comment

                              Working...
                              X