Announcement

Collapse
No announcement yet.

History failure

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

  • History failure

    Hi Steve,

    Recently added 1st First Alert ZCOMBO smoke/CO alarms to test the hell out of it, and figured my main worries would be focused on smoke alarm going off during cooking, but after three days instead I'm now faced with SDJ-Health alerts.

    First time I've seen the skull icon appear, so trying to debug.

    What is weird is that the "Last Good Check" date will be within the 12-hour range, and device entry on battery in HomeSeer shows fine, but your plugin shows skull to say 0% in the SDJ-Health device entry.

    Clicking the history button only shows the Oct 11th entries when I added the sensor, but when I hit the "Test" button on the smoke alarm it immediately updated the battery status and caused SDJ-Health to report green 'OK' battery status again. Unless this only corresponds to a "heartbeat" signal, and not battery levels.

    Want to make sure I don't end up missing history readings on battery values.

    Is it otherwise a simple matter of adjusting the value on "Missed Wake Factor" from the global '0' to 1 or 2 even?

    Device entries:
    Click image for larger version

Name:	Screenshot_2019-10-15 HomeSeer Web Control.png
Views:	233
Size:	17.3 KB
ID:	1333272


    Click image for larger version

Name:	Screenshot_2019-10-15 HomeSeer Web Control(1).png
Views:	122
Size:	17.3 KB
ID:	1333273

    Click image for larger version

Name:	Screenshot_2019-10-15 HomeSeer Web Control(2).png
Views:	121
Size:	29.6 KB
ID:	1333274


    HomeSeer Log:

    Oct-15 18:20:51 Device Control Device: Node 18 Z-Wave BRK Brands Sensor Alarm (Health) to History (2001) by/from: CAPI Control Handler
    Oct-15 18:20:45 Device Control Device: Node 18 Z-Wave BRK Brands Sensor Alarm (Health) to History (2001) by/from: CAPI Control Handler
    Oct-15 18:20:28 SDJ-Health 1 queued messages processed
    Oct-15 18:20:28 SDJ-Health Device #165 recovered from missed wakeup state.
    Oct-15 18:20:28 SDJ-Health Previously Silent Activity Device #165 added to message queue for processing.
    Oct-15 18:20:23 Z-Wave Device: Node 18 Z-Wave Notification Set to Notification OFF for Type 12
    Oct-15 18:20:07 Z-Wave Device: Node 18 Z-Wave Notification Set to Notification ON for Type 12, Level 255
    Oct-15 18:19:39 SDJ-Health PEData read sucessfully from child device #168


    PS: Spell-check kicked in for me on "successfully" and "wake-up" when pasting the logs, and doesn't bother me, but figured I mention it.

  • #2
    Originally posted by RoChess View Post
    Hi Steve,

    Recently added 1st First Alert ZCOMBO smoke/CO alarms to test the hell out of it, and figured my main worries would be focused on smoke alarm going off during cooking, but after three days instead I'm now faced with SDJ-Health alerts.

    First time I've seen the skull icon appear, so trying to debug.

    What is weird is that the "Last Good Check" date will be within the 12-hour range, and device entry on battery in HomeSeer shows fine, but your plugin shows skull to say 0% in the SDJ-Health device entry.

    Clicking the history button only shows the Oct 11th entries when I added the sensor, but when I hit the "Test" button on the smoke alarm it immediately updated the battery status and caused SDJ-Health to report green 'OK' battery status again. Unless this only corresponds to a "heartbeat" signal, and not battery levels.

    Want to make sure I don't end up missing history readings on battery values.

    Is it otherwise a simple matter of adjusting the value on "Missed Wake Factor" from the global '0' to 1 or 2 even?

    PS: Spell-check kicked in for me on "successfully" and "wake-up" when pasting the logs, and doesn't bother me, but figured I mention it.
    Hi RoChess

    I don't have one of these devices so I am shooting a bit blind. Can you post screenshots of the following and I will see if I can figure it out:
    SDJ-Health tab of the monitoring child (#168)
    Status Graphics tab for the Notification Child (#167)

    The battery readings in SDJ-Health should reflect the readings of the battery device in HS3, that's where they come from. It looks like the value was initially 0% and then changed to 100%. The History on the SDJ-Health tab will show the times of the readings as well as the dates. Is that the case and does that show in your HS3 log?

    Thanks for spotting the typos in the error messages I will correct those.

    Steve

    Comment


    • #3
      Originally posted by SteveMSJ View Post

      Hi RoChess

      I don't have one of these devices so I am shooting a bit blind. Can you post screenshots of the following and I will see if I can figure it out:
      SDJ-Health tab of the monitoring child (#168)
      Status Graphics tab for the Notification Child (#167)

      The battery readings in SDJ-Health should reflect the readings of the battery device in HS3, that's where they come from. It looks like the value was initially 0% and then changed to 100%. The History on the SDJ-Health tab will show the times of the readings as well as the dates. Is that the case and does that show in your HS3 log?

      Thanks for spotting the typos in the error messages I will correct those.

      Steve
      I meant to also ask for a screenshot of the Z-Wave Node Information for Node 18.

      Thanks,
      Steve

      Comment


      • #4
        Okay, hope I took all the correct ones, so here goes:
        Click image for larger version

Name:	Screenshot_2019-10-16 Modify Node 18 Z-Wave BRK .png
Views:	100
Size:	495.3 KB
ID:	1333458


        Click image for larger version

Name:	Screenshot_2019-10-16 Modify Node 18 Z-Wave Not .png
Views:	95
Size:	85.1 KB
ID:	1333459


        Click image for larger version

Name:	Screenshot_2019-10-16 Screenshot.png
Views:	95
Size:	36.0 KB
ID:	1333460

        Click image for larger version

Name:	Screenshot_2019-10-16 HomeSeer Web Control.png
Views:	96
Size:	30.2 KB
ID:	1333461


        Whatever else you need, feel free to ask, and I can run SQL queries on your database as well if needed, as I believe you rely on SQLite, but have a feeling the above might be enough. What immediately struck me as odd was the value on the device notifications, such as 13.255, or is that like a 2-byte notation trick of 13 + 255? With the 255 being the 'ON' for it?

        Comment


        • #5
          Originally posted by RoChess View Post
          Whatever else you need, feel free to ask, and I can run SQL queries on your database as well if needed, as I believe you rely on SQLite, but have a feeling the above might be enough. What immediately struck me as odd was the value on the device notifications, such as 13.255, or is that like a 2-byte notation trick of 13 + 255? With the 255 being the 'ON' for it?
          Hi RoChess

          Thanks for the information.
          In terms of monitoring the battery levels, I don't think there is any problem. It looks like when you included the device it first reported a battery level of 0%, which is quite common until some time later when the correct level is reported. The pi recorded a level of 0% at 2:47 pm and then the new level of 100% came through at 3.05PM and it hasn't changed since then. I don't see anything odd about that unless you are saying that there were different values showing for the battery device in HS3. It will probably be a long time before the battery level drops below 100% so you aren't going to get any new readings in the database for a while.

          You currently have the pi monitoring the device using Activity Checking but, whilst this will monitor and alert on battery Levels/Rate/Life fine, it won't be able to monitor whether this particular device is dead or alive. With this particular device neither the root nor any of its children will register any changes unless the battery level changes or the alarm is triggered neither of which will be a regular occurrence. So, if you leave Alert on Wake-Ups set then you will get an alert as soon as the time period expires. Whilst you could extend this by increasing the missed wake-up factor there is little point. If you leave the device like this then I would turn off Alert on wake-ups for this device.

          However, looking at the Status Graphics tab of the Notification child it looks like this device sends a heartbeat which the pi should be able to monitor. This works with ZSmokes and will probably work with your device as the graphics tab looks similar. The trouble with the way the heartbeat works with the ZSmokes is that the device sends the regular heartbeat signal (13.255) but the value doesn't change. HS3 only notifies plug-ins when values change. The way I work round this is the pi sets up an additional Status Graphics pair 13.355 named 'Heartbeat Acknowledged'. The pi then sets the Notification Device to 'Heartbeat Acknowledged' so that when the 'Alarm heartbeat' signal is received HS3 changes the status to 13.255 and informs the pi of the change. The pi then sets it back to 13.355 so the next signal will again cause a change which can be monitored. The pi is only changing the status as shown in HS3 it doesn't send out any commands to the physical device so it doesn't interfere with the device or it's alarm in any way. The Heartbeat is treated as a wake-up and if it stops being received it will trigger an alert in SDJ-Health.

          If you want to try this then uncheck the device from the drop down list of devices to monitor by activity checking and delete the current SDJ-Health monitoring child. Then check the 'MonitorHeartbeats' parameter on the SDJ-Health config page. Leave things running for a while and see how things develop. Any devices like this that are sending a Heartbeat should be detected automatically and monitoring devices created.

          Let me know how it goes.

          Steve

          Comment


          • #6
            Steve,

            Much appreciated on your response, and love the details to learn along the way.

            The 0% first, and then 100% must have been related to insertion of battery first time and how it took a few minutes before it sends the battery status. Battery devices often include at 0% for me until they kick in their polling.

            What worried me is that on the 14th (day before yesterday) I saw the skull icon on dead-device in SDJ-Health (ref #168), but the HomeSeer entry for battery (ref #166) was showing green with a time I assumed matched the 12h polling.

            Waited a bit to see if it was just a missed polling, so then yesterday I finally pushed 'test' button on smoke alarm (covering horn as much as possible to avoid my ears from ringing) and SDJ-Health immediately updated. This then made me realize I should have made more screenshots before I hit that button, but figured logs might reveal.

            Will try your suggestion though, because that is a nice work-around. At first I thought you would recommend I uncheck the box to have HomeSeer update the time to reflect a change even when value doesn't change, but that is not useful for triggers so adjusting the value makes more sense.

            What is weird though is that I never saw the "Alarm Heartbeat" until today, it was always showing the "No Notifications", and it seems to have triggered about an hour after I ran the smoke-alarm test.

            Comment


            • #7
              Originally posted by RoChess View Post
              What is weird though is that I never saw the "Alarm Heartbeat" until today, it was always showing the "No Notifications", and it seems to have triggered about an hour after I ran the smoke-alarm test.
              Not having any knowledge of these devices I don’t know whether the Heartbeat signal is configurable in any way or even if it will work with the pi. I know the ZSmokes work because others have tested them. If I remember correctly the heartbeat is every 60 mins on them.
              Perhaps it took a test to kick it into action. Time will tell. I will keep my fingers crossed.
              Steve

              Comment


              • #8
                If you weren't in the UK I would drop-ship you one, but 908.42 MHz probably not going to work for you.

                Have nine more units sealed in box, so will start to include a couple more. They seem to be operating well, although it is tricky to find placement that avoids false-alarms during for example cooking, while still ensuring real-alarms will go off quickly and not after half the room is on fire

                Part of me was really hoping they were FLiRS compatible, so they would react to Z-Wave commands as well to interconnect them and have the abillity to set off the siren/chirp, or to silence them remotely. The latter desire stems from 5 Kidde alarms going off in different areas of the house after some `cooking` fumes from baking homemade chips escaped the oven with half the house asleep. Replacing the stove hood vent with a more powerful fan is clearly needed as well, but still needed smoke alarms as a lot of the Kidde's have died and accelerated my plans to Z-Wave them.

                Will keep my fingers crossed as well

                Comment


                • #9
                  Should have looked before replying, seems we have a winner:
                  Click image for larger version

Name:	Screenshot_2019-10-16 HomeSeer Web Control(1).png
Views:	89
Size:	30.5 KB
ID:	1333524


                  Click image for larger version

Name:	Screenshot_2019-10-16 HomeSeer Web Control(2).png
Views:	88
Size:	18.1 KB
ID:	1333525



                  Wonder why heartbeat did not kick in by default during the initial inclusion, as I'd rather avoid extra tests with the loud chirps it generates. Will include the new ones in a different way over the spread of one this week, and another one next week, to verify the exact procedure to ensure they work reliable.

                  Comment


                  • #10
                    Your PI perfectly added the 13.355 entry with corresponding graphic to the device status graphic page, but I noticed that none of the other entries have graphics.

                    You wouldn't happen to have nice graphics for the other smoke/CO-alarm conditions?

                    Checking the /html/images/HomeSeer/status folder I see existing images I can use, such as "alarmsmoke.png", so curious why HomeSeer did not automatically create those like it has done for other devices.

                    Probably shouldn't worry about visuals like that yet, but figured I'll forget months down the line when I'm setting up HSTouch. Perhaps an idea for your PI to add those automatically the way it added the 13.355 entry if no other status graphics exist.

                    Probably outside of the scope of your PI, so let me know and I will file a support ticket at support@homeseer.com.

                    Comment


                    • #11
                      Originally posted by RoChess View Post
                      Should have looked before replying, seems we have a winner:

                      Wonder why heartbeat did not kick in by default during the initial inclusion, as I'd rather avoid extra tests with the loud chirps it generates. Will include the new ones in a different way over the spread of one this week, and another one next week, to verify the exact procedure to ensure they work reliable.
                      That's sounds like a useful approach and I look forward to hearing how it goes.

                      Steve

                      Comment


                      • #12
                        Originally posted by RoChess View Post
                        If you weren't in the UK I would drop-ship you one, but 908.42 MHz probably not going to work for you.
                        A kind offer but as you say the UK ZWave frequency is different. I haven't come across a good European ZWave Smoke/C02 detector. I have Fibaro Smoke detectors which I initially raved about as they are really neat, easy to configure and report temperature as well as alerting on smoke and heat. That was before they started randomly throwing false alarms. They work fine for months/years and then one of them will start triggering randomly. This will happen for a few days and then it will settle down for months before another one will start the random triggers. It's no fun being woken in the middle of the night by my internal sirens on full blast and even worse when you have guests staying.
                        Nicely designed units but effectively JUNK!

                        Steve

                        Comment


                        • #13
                          Originally posted by RoChess View Post
                          ....I can run SQL queries on your database as well if needed, as I believe you rely on SQLite...
                          Yes, the database is SQLite so you can use any appropriate editor to view, alter or graph the data.

                          You should also find that if you have to delete a monitoring child for any reason and then recreate it, the history will be retained as the ID of the Root device is used as the key in the database.

                          Steve

                          Comment


                          • #14
                            Originally posted by SteveMSJ View Post
                            That's sounds like a useful approach and I look forward to hearing how it goes.
                            Looking forward myself as well, to a smooth experience that is

                            Wondering if the lack of status graphics was due to me removing devices, so before I create HomeSeer support ticket I'll wait till I've included new ones.

                            Originally posted by SteveMSJ View Post
                            It's no fun being woken in the middle of the night by my internal sirens on full blast and even worse when you have guests staying.
                            I was shocked at myself how much rage went through me when I had to rush to the kitchen to help reach them (helps being 6'7" so I didn't require ladder), but to then be unable to silence the alarm via the test/silence button, taken it outside waving it in fresh air, keep hitting silence button, to finally smacking it hard into concrete out of spite, and then dug around to locate screwdriver to just prematurely end-of-life it.

                            Those new 10-year guaranteed models have built in battery that you can't replace battery on anymore and have to toss entire unit.

                            Glad these new ones work on 2x AA again, and I can safely monitor via SDJ-Health when to replace the batteries on 'my' time, and not when chirps wake me up middle of the night to randomly decide they need new batteries. Alkalines will have a better profile to slowly drop, but I normally use Energizer Lithium batteries for critical sensors, door-locks, etc. Might have to try it on a couple sensors if the Alkalines don't last very long as I love the extra time they provide for the other Z-Wave devices.

                            Sucks for your Fibaro's though, but I know the feeling as my original plan was to go full Nest and use their Nest Protects, but I did not like it when Google took them over and figured I just waited and see until smoke alarms at other location started to near End-of-Life or suck through batteries fast, but proper working units run extremely long and then Google decided to kill Works-with-Nest and I'm totally turning my back on them. Seems the backlash has caused them to do a 180 and are adding API support back in, but I'm hesitant that they might pull a fast one again in the future.

                            Originally posted by SteveMSJ View Post
                            You should also find that if you have to delete a monitoring child for any reason and then recreate it
                            Caught that yesterday, and was nice to see history retained.

                            Comment


                            • #15
                              Hi Steve, sorry for the delay on this, but as I posted in the other thread life took over. Was able to do one batch of testing, and very promising results.

                              Included two FirstAlert Z-COMBO smoke sensors at 9:11:36pm and 9:15:36pm last night, and they immediately showed the three entries for root device, battery, and notification. The battery updated to 100% in a short time, but Notifications did not report a heartbeat until 11pm and the most recent one is from 35 minutes ago. The moment when the first heartbeat occurred, the SDJ-Health plugin modified the notification status page by adding the 13.355 text entry for heartbeat acknowledgement and the corresponding status image.
                              I did uncheck the checkbox to not update the time, so next batch I will not do that. Should then still work the way it works as notifications will switch between "Heartbeat", and "Heartbeat Acknowledged".

                              Comment

                              Working...
                              X