Announcement

Collapse
No announcement yet.

Help on increase in warnings and errors

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

  • Help on increase in warnings and errors

    I have noticed an increase in messages since I installed the plugin. This could have nothing to do with the plugin but I thought I would post here to see if there is any connection.
    Apr-13 10:28:43 AM Z-Wave Warning Not all queued commands could be sent to Home Theater Basement Home Theater - Fibaro Notification Sensor Root and there are already 9 commands in the queue. Failed commands will NOT be re-queued for processing later.
    This one seems to always come from this one Fibaro sensor. According to SDJ-Health it is showing fine.
    Apr-13 8:06:53 AM Z-Wave Z-Net: Z-Wave Wake-Up 'No More Info' Notification error sending to Node 67(Dining Room Ground Floor Dining Room - Aeon Labs Multi Sensor Root).
    Apr-13 8:05:53 AM Z-Wave Warning Queued command (Unknown) failed for Dining Room Ground Floor Dining Room - Aeon Labs Multi Sensor Root and is being re-queued for the next wake-up interval.
    This one is more ubiquitous and is occurring with many of the z-wave battery powered sensors. I do see that routinely there are devices that miss their poll - but this situation seems to clear. This happens so much that I removed the yellow battery warning from my touchscreens when SDJ-Health had a missed poll condition because it was on more than it was off.

    Again, this may be nothing to do with the plugin but any thoughts would be great. Thanks.

  • #2
    Originally posted by simonmason View Post
    I have noticed an increase in messages since I installed the plugin. This could have nothing to do with the plugin but I thought I would post here to see if there is any connection.
    Apr-13 10:28:43 AM Z-Wave Warning Not all queued commands could be sent to Home Theater Basement Home Theater - Fibaro Notification Sensor Root and there are already 9 commands in the queue. Failed commands will NOT be re-queued for processing later.
    This one seems to always come from this one Fibaro sensor. According to SDJ-Health it is showing fine.
    Apr-13 8:06:53 AM Z-Wave Z-Net: Z-Wave Wake-Up 'No More Info' Notification error sending to Node 67(Dining Room Ground Floor Dining Room - Aeon Labs Multi Sensor Root).
    Apr-13 8:05:53 AM Z-Wave Warning Queued command (Unknown) failed for Dining Room Ground Floor Dining Room - Aeon Labs Multi Sensor Root and is being re-queued for the next wake-up interval.
    This one is more ubiquitous and is occurring with many of the z-wave battery powered sensors. I do see that routinely there are devices that miss their poll - but this situation seems to clear. This happens so much that I removed the yellow battery warning from my touchscreens when SDJ-Health had a missed poll condition because it was on more than it was off.

    Again, this may be nothing to do with the plugin but any thoughts would be great. Thanks.
    I don't think these are to do with SDJ-Health but more to do with the ZWave pi queuing commands and polls for non-listening ZWave devices. SDJ-Health doesn't poll non-listening devices.

    The first error looks like an issue with queued commands being sent to a non-listening ZWave device. SDJ-Health doesn't send any commands so it is most likely that you have automatic polling set for some devices or events that are sending commands or polling for status. I have had this sort of issue with my StellaZ radiator valves which have to be polled for values and I send device values for setpoints etc. I have very occasionally had HS stop being able to send the commands so the queue fills up. A full shutdown of the HS PC and restart has cured the issue for me. In my case I think the UZB stick might have been causing the problem and fully powering off the PC, with the UZB stick attached, helped rather than just a restart. Bear in mind this has only occurred a couple of times in several years and I wasn't able to pin down what caused it.

    The second error is something that appears regularly in the log since around ZWave pi 3.0.1.243. There are a few threads about it, e.g. https://forums.homeseer.com/forum/li...-other-devices. It isn't anything to do with SDJ-Health and apparently HS have said it is normal and doesn't necessarily indicate any problems.

    The third error is one I get with the StellaZ's when I try and set or read more than one or two child devices of the physical device at the same wake-up. I think it is caused by the device going back to sleep before the queued commands have been completed. It could be trying to send to many commands at a single wake-up or a sign of communication problems. With the StellaZ's the command normally succeeds at the next wake-up.

    Are you also saying that you have some listening ZWave devices that you have set SDJ-Health to monitor by polling that are regularly failing a poll? If so this might be a sign of communication problems on your ZWave network. What are the devices?
    If you set the SDJ-Health logging level to 2 (debug) you will get more information about what SDJ-Health is up to.
    Again I would try a restart of the PC and your ZWave controller if it is separately powered.

    If a device only occasionally fails the odd poll, due to communication issues, you could increase the 'Missed Wake Factor' for that device on the SDJ-Health tab so that it doesn't report as a failure until a few are missed in a row. Remember to click the Save button when you change any of the local parameters on the SDJ-Health tab of a monitoring device. You can also turn off Alerts on Missed Wake-ups for individual devices and just monitor the levels if you want. These are all band-aids though and it would be better to establish why a devices is failing polls.

    Steve

    Comment


    • #3
      Thank you for the detailed summary. I actually have another thread going on polling, and even with the homeseer folks responding I am still not getting clear answers. If you don't mind adding your expertise in further...

      On the first issue, I had the device set through the polling option at 15 minutes. I use it to measure the temp in my home theater and adjust the heat accordingly as there is a supplemental heater in there with no thermostat. I am guessing the correct way to do this is to wake it up and adjust the internal z-wave function to report temp changes every 15 minutes?

      On the second issue I will read up on the links. Thanks.

      On the third issue - this is happening with a lot in my log - about every 20 minutes with most of my z-wave batter devices. Should I just ignore it?

      Thanks.


      Comment


      • #4
        Originally posted by simonmason View Post
        Thank you for the detailed summary. I actually have another thread going on polling, and even with the homeseer folks responding I am still not getting clear answers. If you don't mind adding your expertise in further...

        On the first issue, I had the device set through the polling option at 15 minutes. I use it to measure the temp in my home theater and adjust the heat accordingly as there is a supplemental heater in there with no thermostat. I am guessing the correct way to do this is to wake it up and adjust the internal z-wave function to report temp changes every 15 minutes?
        I'm no expert but I will expand on my personal experience.

        Whether and how you poll depends very much on the particular device details. What actual device is this? Polling (especially frequent) should generally be avoided unless absolutely necessary. Most modern Z-Wave devices, including battery devices, don't need to be polled, they report data at intervals which can usually be configured by adjusting their parameters. The only devices I have that require polling for data and sending commands are my StellaZ radiator valves which I hate! Whilst in theory the Z-Wave transmission rate is reasonably high, in practice it is very slow to poll listening devices. In my experience a successful poll of a listening device can take up to 2 seconds and one that fails up to 10 seconds. I'm pretty sure that Z-Wave transmissions are serial and the network is basically paused during this time.

        Non-listening battery powered devices can be polled by HS but the polls are queued until the device announces a wake-up, which is at an interval that can normally be set in the device. If the device cannot be configured to send information but needs to be polled there is no point in polling it more frequently than it's wake-up interval (or perhaps a few seconds shorter). When a device wakes-up it announces this to HS which will then request information if there are queued polls. Whilst the device is supposed to stay awake until no more information is requested they usually have a fairly short maximum time period before they go back to sleep, even if HS is still interrogating them. So, if the device has several child devices, polling them all at a wake-up may well fail. Polling the root device causes HS to poll all the child devices so again this can cause problems. Also, if there are communication issues on the network polls may fail as the device will go back to sleep before the poll is completed. The StellaZs have several child devices including temperature, valve position, mode and 3 setpoints. My experience is that polling one child device is almost always successful, polling 2 is usually ok but any more nearly always fails.

        The other thing about polling is that if there are any issues with communications on your network polling listening or non-listening devices is likely to exacerbate them as failed polls take significant time.

        In your particular case I'm not sure what actual device your Fibaro Notification Sensor is but in my experience none of the Fibaro devices require polling for information. You should be able to set it to send temperature readings at whatever interval you require or when the temperature changes by a certain amount. A slight aside but if you are controlling a heater without a physical thermostat you might want to look at my Virtual Thermostat plugin SDJ-VStat.

        Originally posted by simonmason View Post
        On the second issue I will read up on the links. Thanks.
        Ok.

        Originally posted by simonmason View Post
        On the third issue - this is happening with a lot in my log - about every 20 minutes with most of my z-wave batter devices. Should I just ignore it
        It looks like you have communication issues on your network which are causing polls to fail. This might just be due to too much polling or might be due to too greater distance between devices, or a rogue device swamping the network. Anyway, you shouldn't be polling the Aeon Multisensors as they can be configured to send out sensor readings without polling. Whether on batteries or USB powered they can be set to send information in groups. If on batteries the minimum reporting period for these is limited by the wake-up interval so you need to consider both when configuring the device. I have several of these, although only one on batteries. They are generally good devices although battery life is poor.

        Returning to SDJ-Health this only uses polling as an optional method of testing whether a Listening type battery device is still alive. You can configure the polling interval, default being 6 hours, and any devices you select are staggered over the time period. If you have 6 devices being monitored by polling then this only results in 1 poll every hour which should have an insignificant impact on a network.

        I hope this helps,

        Steve

        Comment


        • #5
          I am not individually polling any of these devices. They are all set to 0 hours/minutes/seconds on the z-wave tab. Most are setup to wake up and report based on certain time intervals I have set or when triggered.

          I do have the "Enable Polling" checkbox on in the Z-wave configuration. I was advised in another thread by Homeseer to turn that off. I did, and then started to see some anomalies around the house. For example I have a number of rooms with Leviton switches that allegedly report instant status. I use this to trigger lighting scenes in the room. As soon as I turned off the "Enable Polling" option in the z-wave configuration these stopped working. As I understand it, if "Enable Polling" is off then this should not impact the instant status communication from these switches.

          But I continue to get issues in the log (see attached). None of these devices are being polled. This is a relatively new phenomenon - I wasn't seeing these errors before. I don't know if there was a recent z-wave update that might have started all of this?

          Comment


          • #6
            Originally posted by simonmason View Post
            I am not individually polling any of these devices. They are all set to 0 hours/minutes/seconds on the z-wave tab. Most are setup to wake up and report based on certain time intervals I have set or when triggered.

            But I continue to get issues in the log (see attached). None of these devices are being polled. This is a relatively new phenomenon - I wasn't seeing these errors before. I don't know if there was a recent z-wave update that might have started all of this?
            Looking at your log snippets something is trying to poll devices. If, for example, we focus on node 71 you have a warning message that implies that when this device woke up a queued command failed to be sent and that command was Poll Device. Node 71 appears to be an Aeon Labs Multisensor.

            To try and figure out what is going on can you go to PLUG-INS>Z-Wave>Node Information and post a screenshot of all the information displayed for Node 71?

            Originally posted by simonmason View Post
            I do have the "Enable Polling" checkbox on in the Z-wave configuration. I was advised in another thread by Homeseer to turn that off. I did, and then started to see some anomalies around the house. For example I have a number of rooms with Leviton switches that allegedly report instant status. I use this to trigger lighting scenes in the room. As soon as I turned off the "Enable Polling" option in the z-wave configuration these stopped working. As I understand it, if "Enable Polling" is off then this should not impact the instant status communication from these switches.
            I am not familiar with the Leviton switches but it is possible that these are not true Instant Status. If so, HS uses a sudo instant status under the hood. As long as there is direct communication with the controller this detects when the device has been changed and immediately polls it for it's status. I guess this sudo instant status is turned off when Enable Polling is deselected.

            Steve

            Comment


            • #7
              Here is a screen shot of node 71.

              I will do some more experimenting with the Leviton switches. But if I understand this correctly - the "Enable Polling" option in the z-wave settings controls some sort of background polling that is unrelated to the settings in the individual devices. That means Homeseer is essentially polling these devices continuously looking for status changes?

              Comment


              • #8
                Originally posted by simonmason View Post
                Here is a screen shot of node 71.
                This screenshot shows that you have HS set to poll all the child devices at roughly 20 minute intervals apart from the battery child which is 12 hours. The Polling Disabled at the top right is only for the root device it doesn't stop the children being polled. This explains why you have queued poll requests which are being executed when the device wakes up.
                There should be no need to poll any of the Aeon Labs devices, including the battery. Go to the Z-Wave tab of each one in turn and set the polling interval to 0 which means off.

                It may well be that these polling intervals were set automatically by HS if you added the device on an old version of the Z-Wave plugin. It used to set these random 20 minute polling intervals but that was removed in later versions of the plug-in.

                Another point to note is that your screenshot is showing the manufacturer as Sigma Designs and the Version Information not available. This indicates that the devices probably wasn't successfully scanned when originally included or the information has got corrupted at some point. You might want to try a re-scan of the root device to see if it picks up the information correctly but you will need to wake it up and ensure it stays awake whilst scanning. It also shows it doesn't have direct communication with your controller which might give you trouble scanning unless you can temporarily move them closer together.

                Don't delete the root or any of the child devices or new devices will be created! However, HS has a habit of creating a new luminance child when some devices are re-scaned.

                Which version of the Multisensor is this?

                Originally posted by simonmason View Post
                I will do some more experimenting with the Leviton switches. But if I understand this correctly - the "Enable Polling" option in the z-wave settings controls some sort of background polling that is unrelated to the settings in the individual devices. That means Homeseer is essentially polling these devices continuously looking for status changes?
                Not exactly, the Enable Polling checkbox if deselected turns off all polling, as far as I know, it's a sledgehammer.
                The old switches that HS uses sudo instant status aren't being polled continuously. If they have direct communication with the controller HS receives a notification when their state changes and then polls the device to get the status value. I would imagine that action is also turned off if you disable all polling.

                Steve

                Comment


                • #9
                  This was a bit of an eye opener. I had been concentrating on the root devices. I did not set any of these polling intervals on the child devices. I rescanned the Aeon Labs sensors that showed Sigma Designs and in each case the homeseer recognized them as Aeon Labs. I have two older sensors - the four in ones. I also have a newer 6 in 1 that apparently scanned fine when I installed it recently. Also, the newer sensor didn't have any polling times set except the battery at 12 hours.

                  I have a bunch of devices where the battery polling is set to 12 hours. I uploaded some pictures of one of these - an aeon labs sensor that I have hooked to my doorbell to let me know when it is pressed. I cleared out the 12 hour battery poll - but now I am wondering if I should have done this as I don't see anything in the root about reporting battery status? I am assuming that in the event the root doesn't have a setting for reporting battery then you have to put the polling in place?

                  Thanks again for helping out with this - it has been good to figure this out. Hopefully it will result in last z-wave activity on my network.

                  First image is the battery reporting - which was set to 12 hours and I zeroed it out.
                  Second is the node info.
                  Third is the root settings.

                  Comment


                  • #10
                    Originally posted by simonmason View Post
                    This was a bit of an eye opener. I had been concentrating on the root devices. I did not set any of these polling intervals on the child devices. I rescanned the Aeon Labs sensors that showed Sigma Designs and in each case the homeseer recognized them as Aeon Labs. I have two older sensors - the four in ones. I also have a newer 6 in 1 that apparently scanned fine when I installed it recently. Also, the newer sensor didn't have any polling times set except the battery at 12 hours.

                    I have a bunch of devices where the battery polling is set to 12 hours. I uploaded some pictures of one of these - an aeon labs sensor that I have hooked to my doorbell to let me know when it is pressed. I cleared out the 12 hour battery poll - but now I am wondering if I should have done this as I don't see anything in the root about reporting battery status? I am assuming that in the event the root doesn't have a setting for reporting battery then you have to put the polling in place?

                    Thanks again for helping out with this - it has been good to figure this out. Hopefully it will result in last z-wave activity on my network.

                    First image is the battery reporting - which was set to 12 hours and I zeroed it out.
                    Second is the node info.
                    Third is the root settings.
                    You may need to have the battery device polled, it will be depend on the model. You could consult the detailed manual for each device but it's not much of an overhead to poll every 12 hours even if not strictly required. I have a relatively new Aeon Multisensor that doesn't need the battery polling but I think some of the older ones did. If you have a wakeup interval set at 12 hours then setting the polling of the battery child to a few seconds less than 12 hours will ensure no wake-ups are missed (not that missing one now and again would matter).

                    Not all root devices will show the specific settings, it depends whether HS have added them to the page. You can still read and set parameters on the root device by referring to the parameter numbers in the device's manual.

                    One other point is that both devices you have posted screenshots for (Node 71 and Node 82) don't have a direct path to your Z-Net but are routing through Node 20 at a reduced speed of 40Kbps. You may want to think about the location of you Z-Net to try and improve communications. If you have Z-Seer it is a useful tool for examining and adjusting the routing of your network.

                    Steve

                    Comment


                    • #11
                      ok, I have downloaded z-seer so now I need to start reading up on the documentation and figuring out how to use it.

                      Comment

                      Working...
                      X