HS3 Beta 3.0.0.300 Discussions

[rjh]

See HS3 release notes for changes.

http://board.homeseer.com/showthread.php?t=181241

[jhearty]

I heard this has a battery status fix in it. One person indicated it so far seems to have resolved reporting issues on one device model they had issues with. Any other folks try it and have good news?

Is there a linux version? I'm on .293 and it shows no beta available, .297 as the last GA available.

[rmasonjr]

I updated mine by going to a command prompt and:

cd /usr/local/HomeSeer
./updatehs.sh 300
sudo reboot

I'm hopeful this fixes my battery issues - will let it run a couple of days first...

[garyd9]

I updated mine by going to a command prompt and:

cd /usr/local/HomeSeer
./updatehs.sh 300
sudo reboot

Wow... this message confused me. "Command prompt" is a term I usually associate with Windows, not with linux, so I was trying to figure out why you were using forward slashes (and sudo) with windows. I had to stop and actually use my brain. It was scary.

I don't seem to have a "updatehs.sh" script on my machine... I have an "update.sh" but seems to expect a full archive name that already exists on the machine as a parameter, AND running it (with the .300 archive) in the homeseer directory wouldn't do much good, as it'd create a new subdirectory (so you'd have /usr/local/HomeSeer/HomeSeer - with the new version in the deepest nested directory.)

It sounds as if your updatehs.sh script does a wget (or curl) to download the specified version, and unarchives it from the parent directory? Is this something of your own creation, or perhaps something that used to exist in previous HS3 archives?

Can you share the script?

Thanks
Gary

[garyd9]

See HS3 release notes for changes.

+=

The previously released HS3 version on linux was 297. In addition to the listed changed items, it appears that the 300 archive also includes several image files that were missing from the linux archive (but where included in the Windows installer) such as those used for the "central scene" z-wave command class.

[rmasonjr]

Wow... this message confused me. "Command prompt" is a term I usually associate with Windows, not with linux, so I was trying to figure out why you were using forward slashes (and sudo) with windows. I had to stop and actually use my brain. It was scary.

I don't seem to have a "updatehs.sh" script on my machine... I have an "update.sh" but seems to expect a full archive name that already exists on the machine as a parameter, AND running it (with the .300 archive) in the homeseer directory wouldn't do much good, as it'd create a new subdirectory (so you'd have /usr/local/HomeSeer/HomeSeer - with the new version in the deepest nested directory.)

It sounds as if your updatehs.sh script does a wget (or curl) to download the specified version, and unarchives it from the parent directory? Is this something of your own creation, or perhaps something that used to exist in previous HS3 archives?

Can you share the script?

Thanks
Gary

Yup - here is the script - it just does a wget with the version number passed-in:

homeseer@RPi2 /usr/local/HomeSeer $ cat updatehs.sh
sudo rm hslinux_hs3_3_0_0_$1.tar.gz
sudo wget http://homeseer.com/updates3/hslinux_hs3_3_0_0_$1.tar.gz
sudo tar xavf hslinux_hs3_3_0_0_$1.tar.gz
sudo chmod +x install.sh
sudo ./install.sh

homeseer@RPi2 /usr/local/HomeSeer $ 

[garyd9]

This does NOT appear to be fixing the problem completely. Please see the attached image showing the "last changed" for my "toy room window sensor battery", a log entry showing that the value was polled, and the configuration showing that the option which would prevent updating the timestamp NOT selected.


(Oddly enough, the second line shown in the log is polling for a garage door sensor, and the timestamp for THAT device did update.)

[Daweeze]

Here's the log entries for one of my wireless smoke alarms that shows the battery was updated on the Device screen last at 3:58:40 PM.

All is well here with the update...

Note that the Event I have there is a heartbeat even so I can track when the node has not communicated after a couple of hours. The fact that it is present in the log means that the Node called in to report at that time which not only reset the timer but allowed it to update the battery status. The Battery status only updates every 12 hours and each node appears to randomly report in to do it. It's not like the all report at 6PM and 6AM etc...

-Travis

[langenet]

I wish the release notes were published consistently for all versions.
I sent in a request for the release notes for .298 on November 3rd and was told they would be updated shortly... Still waiting...

Robert

[garyd9]

Here's the log entries for one of my wireless smoke alarms that shows the battery was updated on the Device screen last at 3:58:40 PM.
...
Note that the Event I have there is a heartbeat even so I can track when the node has not communicated after a couple of hours. ...

With the particular bug of z-wave battery statuses not having the "last change" timestamp updated... the bug doesn't seem to appear if there's an event based on the device's battery state/value. This was true for 297 and appears to also be true for 300.

(I had used this to work around the bug... I had one massive event with several OR's that would check if any battery levels were below 20%... and the existence of that event resulted in the timestamps updating.. I deleted the event in order to test this build.)

So far, since I installed 300 (and removed the above mentioned event), I've seen 7 non-listening devices have their battery status polled on wakeup. 4 of the 7 have had the timestamp updated. The remaining 3 have NOT had their timestamp updated.

It doesn't seem to matter if the devices are same/different models, z-wave plus or not, etc. It also doesn't seem to matter if I'm using the beta z-wave plugin (.95) or the older "release" version (.87.)

[sparkman]

This does NOT appear to be fixing the problem completely. Please see the attached image showing the "last changed" for my "toy room window sensor battery", a log entry showing that the value was polled, and the configuration showing that the option which would prevent updating the timestamp NOT selected.


(Oddly enough, the second line shown in the log is polling for a garage door sensor, and the timestamp for THAT device did update.)

Could it be that it did not reply to the poll?

Cheers
Al

[Yoja]

Run_On_Value_Change

When will this be fixed?

http://board.homeseer.com/showthread...n_Value_Change

[garyd9]

Could it be that it did not reply to the poll

Of course. It could also be that the reply was lost in noise, etc. The plugin logs when it sends the polls, but doesn't log if/when there's a reply.

To be more clear: with the options I currently have selected, there are no log entries for any poll replies unless a device value actually changes. I don't know of any logging option that would show non-changing replies in the HS log.

On the other hand, the timestamps for all my battery devices did update at least once each overnight. At least two devices had a timestamp older than the most recent poll. (In other words, at least two devices were polled more than once last night, and the most recent poll did not result in the timestamp being updated.) One of those two devices is about 10 feet from the z-wave smartstick+, and the poll was at a time where there was no other activity shown in the log (suggesting a low likelihood of z-wave collisions.)

This (last night) was with the released (non-beta) z-wave plugin (.87.) I seem to have better luck with that plugin for some reason.

[garyd9]

More information...

With various extra logging enabled, here's a WORKING sequence I normally see when a non-listening device wakes up and HS polls for the battery (log entries are in reverse chronological order - newest on top):

Nov-17 11:31:18	 	Z-Wave	SmartStick+: Z-Wave Wake-Up 'No More Info' Notification sent to Node 45(Basement Garage Denise's Garage Door Sensor (Control Device)).
Nov-17 11:31:18	 	Z-Wave	ApplicationCommandHandler from node 45 HANDLING: COMMAND_CLASS_BATTERY Frame(7)=3
Nov-17 11:31:18	 	Z-Wave	SmartStick+: Sending to node 45 (UnSecured) CC=COMMAND_CLASS_WAKE_UP
Nov-17 11:31:18	 	Z-Wave	SmartStick+: Device (Node 45) woke up and Poll Device for Basement Garage Denise's Garage Door Sensor Battery was successfully sent.
Nov-17 11:31:18	 	Z-Wave	SmartStick+: Sending to node 45 (UnSecured) CC=COMMAND_CLASS_BATTERY
Nov-17 11:31:18	 	Z-Wave	SmartStick+: Wake-Up Notification Processing for Node 45 (Basement Garage Denise's Garage Door Sensor (Control Device))
Nov-17 11:31:18	 	Z-Wave	SmartStick+: Z-Wave Wake-Up Notification Received for Node 45

However, in one case (where the battery timestamp did NOT update) I see the following sequence instead:

// missing "z-wave wake up 'no more info' sent" line

// missing applicationcommandhandler handling CC battery

Nov-17 11:22:44	 	Z-Wave	SmartStick+: Sending to node 16 (UnSecured) CC=COMMAND_CLASS_WAKE_UP
Nov-17 11:22:44	 	Z-Wave	SmartStick+: Device (Node 16) woke up and Poll Device for Main Toy Room Toy Room Window Sensor Battery was successfully sent.
Nov-17 11:22:44	 	Z-Wave	SmartStick+: Sending to node 16 (UnSecured) CC=COMMAND_CLASS_BATTERY
Nov-17 11:22:44	 	Z-Wave	SmartStick+: Wake-Up Notification Processing for Node 16 (Main Toy Room Toy Room Window Sensor (Control Device))
Nov-17 11:22:44	 	Z-Wave	SmartStick+: Z-Wave Wake-Up Notification Received for Node 16

What is missing (from the log where the battery timestamp doesn't update) is a line showing the response to the battery poll (which would appear similar to "ApplicationCommandHandler from node 16 HANDLING: COMMAND_CLASS_BATTERY...") and also a line showing that the smartstick sent the "no more info" command. The missing battery response MIGHT be because the device simply didn't send a battery response (which might indicate a problem with the device.)

However, I don't understand why the log line stating "Z-Wave Wake-Up 'No More Info' Notification sent..." doesn't appear. I can see the lower level log entry showing that the COMMAND_CLASS_WAKE_UP is sent (which likely contains the "no more info" command.)

Rich, what can cause the z-wave plugin to NOT log "z-wave wake-up 'no more info'" line? Is it possible that somehow the thread handling the message exchange is terminating prematurely?


UPDATE:

I'm starting to think that either something is wrong with that particular sensor, or HS3 just doesn't like that particular sensor for some reason. Here's the logging from the latest "wakeup" from it: (Note that I had queued commands for polling the battery AND for changing the wake up time to 1 hour in order to get more logging data)

Nov-17 14:23:37	 	Z-Wave	SmartStick+: Sending to node 16 (UnSecured) CC=COMMAND_CLASS_WAKE_UP
Nov-17 14:23:37	 	Z-Wave	SmartStick+: Device (Node 16) woke up and Poll Device for Main Toy Room Toy Room Window Sensor Battery was successfully sent.
Nov-17 14:23:37	 	Z-Wave	SmartStick+: Sending to node 16 (UnSecured) CC=COMMAND_CLASS_BATTERY
Nov-17 14:23:37	 	Z-Wave	SmartStick+: Device (Node 16) woke up and Set Wakeup Interval command was successfully sent.
Nov-17 14:23:37	 	Z-Wave	Successfully set wake up interval for node 16 to 3600
Nov-17 14:23:37	 	Z-Wave	SmartStick+: Sending to node 16 (UnSecured) CC=COMMAND_CLASS_WAKE_UP
Nov-17 14:23:37	 	Z-Wave	Setting wake-up interval for device Main Toy Room Toy Room Window Sensor (Control Device) to 1 hours and 0 minutes.
Nov-17 14:23:37	 	Z-Wave	SmartStick+: Wake-Up Notification Processing for Node 16 (Main Toy Room Toy Room Window Sensor (Control Device))
Nov-17 14:23:37	 	Z-Wave	SmartStick+: Z-Wave Wake-Up Notification Received for Node 16

Again, I don't see "ApplicationCommandHandler" lines for the sent commands (which I believe are logs showing the z-wave responses from the device) and I don't see the generic "SmartStick+: Z-Wave Wake-Up 'No More Info' Notification sent..." line. I'll know in about 35 minutes if the change to the wake-up interval was properly handled by the device...

[mrhappy]

Could I ask if there are other changes that are not on the release notes, I have seen this post by spud here http://forums.homeseer.com/showpost....&postcount=282 that suggests that there may have been changes to the MyHS interface to enable some plugins to pass through it (?) - would it be possible to get an idea of what these might be/mean?