Jump to content

Welcome to Smart Home Forum by FIBARO

Dear Guest,

 

as you can notice parts of Smart Home Forum by FIBARO is not available for you. You have to register in order to view all content and post in our community. Don't worry! Registration is a simple free process that requires minimal information for you to sign up. Become a part of of Smart Home Forum by FIBARO by creating an account.

 

As a member you can:

  •     Start new topics and reply to others
  •     Follow topics and users to get email updates
  •     Get your own profile page and make new friends
  •     Send personal messages
  •     ... and learn a lot about our system!

 

Regards,

Smart Home Forum by FIBARO Team


Z-wave monitor 3.0

   (13 reviews)

7 Screenshots

About This File

This scene monitors and catches Z-wave commands traffic between controller and devices. The data displayed to user as a table which includes total commands and their properties per device, in addition same data displayed at graphical chart and shows system activities over the time. Since Z-wave protocol is not a fastest one  (in many case it's just freeze) this code helps to analyze the data and to take necessary actions to reduce overall Z-wave traffic and system load.

Scene functionality

1. This is not an auto started scene. You need to start it manually. While the scene is running, you can switch views  between table/chart and  monitor (follow instructions on screen).

2. User configurable parameters are:

gVar = true-- Create and use global predefined variable. The scene could work with local table as well, but by using global parameter you can keep history of the traffic. It very helpful when you're updating the system to new release, to compare Z-wave performance. In case you have decided to use global variable, copy the data to other variable to keep the history. To view data of saved variable please download and use Z-wave Viewer scene.  Z-wave Viewer could be executed in parallel to Z-wave Monitor as well (when using global variable only)

logRate = 5     -- Time rate in minutes to log Z-wave activity. Used as axis X scale in charts view. Reasonable value 5 to15 minutes for 24 hours of monitoring. In case to achieve better resolution the value could be decreased down to 1 minute.
time2monitor = 6   -- Time-slot in hours to monitor z-wave traffic, after that time, table and chart will be displayed on debug window and scene will stopped. Value of  0 hours disables auto ending. User needs to stop the monitoring. If less than hour monitoring required please use decimal fraction. For example to set monitor time to 15 minutes set, time2monitor = .25

 markId = "|0|0|", " Cyan" -- Devices (IDs) list and text color to display specific devices in defined color at monitor view for follow up purpose. In few cases you need to monitor specific device, so fill-in the device ID and it will be highlighted by different color from other devices.
deadOnTop = {true, "maroon"}  -- Display DEAD devices on top of the monitor view list in defined text color. Since we're not always looking on the screen, so in case the system will identify dead device it will continuously display the device (in red) on debug window.

 

All variables below are the same for Z-wave Monitor  and  Z-wave Viewer
chartHeight = 100        -- Chart height in percents (%). Chart's default height fits debug window.  The variable changes height of all charts (devices.scenes and events)
chartWidth = 100         -- Chart width in percents (%). Chart's default width expands according to number of samples.  User could expand the width  to get better detail view or to stretch to visualize the load on time axis or to take snap shot of entire time line. The variable changes width of all charts (devices.scenes and events)

 

topDev2disp = 6          -- Number of most active devices to display on devices chart.  If set to zero chart won't be displayed.
topScene2disp= 10        -- Number of most active scenes to display on scenes chart. If set to zero chart won't be displayed.

darkSkinMode = true      -- Charts display skin mode. Set false for light (white) skin.

dev2review={false,"|470|804"} -- Generate chart for every device in list of actual device readings over the monitoring time. For devices with two results (like power and energy) both reading will be displayed. On left and right sides of the chart  applicable scale displayed. Please note, no chart is generated for devices like motion, door and any other sensors, which provide values of true/false.
userDev={false,"|504|_531|"} -- User defined devices and scenes IDs to generate specific combined chart. Please write underscore before scene ID |_531| 

stackedChart=true        --  A stacked line chart is an line chart in which lines do not overlap because they are cumulative at each point. Set to false to view standard line char. All charts except ZKG chart (events,CPU and RAM) will be displayed according to this variable.

 

 

 

Brief explanation what is displayed:

1. Monitor view

Spoiler

Monitor.thumb.PNG.03a79c7e67f6ed17b938e4a6816358cc.PNG

This snap shot includes top and dead devices marked in different color from other devices.

Two main sections in this view:

Header

             1:08:07/ 6:00:00               1824 events/77 devices            event/2.3s               (Click Start for )

    Elapsed Time/Monitoring time             Number of Z-wave events/devices          Z-wave traffic rate        Click to switch to table/chart view

               

Devices list

Every device displayed at follow format -

 #2/34TV509@Salon(216.7 power

#2/34 -First number is number of events during logRate slot. Second number is total number for events so far.

TV509@Salon - device name, ID and room name

(216.7 power) - actual reading and reading property

 

 

2. Table view

Spoiler

Capture.thumb.PNG.b5997f3c8e4aa29e1831a47c8ede2f31.PNG

total # - number of total Z-wave events on device

total %  - Percentage of device's events of total system Z-wave events.

All yellow marked headers are received Z-wave properties, except two properties, dead and deadReason which are marked in red. For each device displayed the total number of this specific properties. Red marked ID, means that device was or is "dead" 

By hovering mouse over device IDs, device and room names will be display (tool-tip) at popup box.

At the end displayed few extra summaries 

Spoiler

Capture1.PNG.8065d5ab4803b5c68ddef7ddcf2a9871.PNG

 Elapsed time and Start-End timestamps

Sample log rate as defined by user. Total samples during monitoring time

Total Z-wave events and total number of active devices

Average Z-wave traffic rate

Z-traffic range. Shows the highest and lowest z-wave activities during monitoring time.

If dead devices have found, list of them is displayed

 

3. Most active devices chart

Spoiler

Capture.PNG.e90b7a56fa3058c789857fa0fb5ffdc1.PNG

Spoiler

Capture.thumb.PNG.f369d5fdde5948a8cabf0de9622d4d68.PNG

Example of stacked chart

This chart shows events number of most active devices ( up to number of all active devices allowed by setting topDevNum variable ) on monitoring time-line. On the right-upper corner displayed ID, name and room of the device. By hovering mouse on diagrams or legend, selected item will emphasized in bold to make the item more visible.

 

4. Most active scenes chart

Spoiler

Capture1.thumb.PNG.e38fafcb73177760815771169191cb2e.PNG

This chart shows triggers number of most active scenes ( up to number of all triggered scenes allowed by setting topDevNum variable ) on monitoring time-line. On the right-upper corner displayed ID, name and room of the scenes. By hovering mouse on diagrams or legend, selected item will emphasized in bold to make the item more visible.

5. Review device's actual readings - (dev2review)

Spoiler

Capture.thumb.PNG.f1fd2093d8d91a7f1dec7382596a7170.PNG

For devices with two results (like power and energy) both reading will be displayed. On left and right sides of the chart  applicable scale displayed.

This chart most useful to identify  if device configured to send reports interval at high rate and " differ in readings to send report" set to very low value.

By hovering mouse over the chart, will scale down the diagram to make visible entire range. In case the horizontal scrollbar is not in the middle of the chart , the diagram will flicker.

  

 

 

6. User defined combined chart

Spoiler

Capture.thumb.PNG.f2aa40a059c15f756bf6a3c7416ec0c9.PNG

In some cases we  need to inspect behavior of some devices and scene that triggered by the device. This chart shows user defined devices and scenes on monitoring time-line. On the right-upper corner displayed ID, name and room of the scenes and/or device. By hovering mouse on diagrams or legend, selected item will emphasized in bold to make the item more visible.

 

 

 

7. ZKG Chart View

Spoiler

Capture.thumb.PNG.70eb773105c5db8d90d4045e1c22b3a2.PNG

Chart view shows Z-wave traffic and system load on time line (based on logRate value). You actually could see your smart home beating heart (like EKG). I have named as ZKG (Z-wave cardiogram). Now it's possible to see the "rush" and "quiet" hours of the system.

Chart view includes 5 diagrams displayed over time-line of monitoring period. The diagrams are:

  1. Z-wave events
  2. Triggered scenes
  3. CPU1  percentage
  4. CPU2  percentage
  5. RAM  percentage

At top-right corner of the screen, displayed legend of the diagrams and colors.

Events total number in same color as a diagram line.

CPU1 min  > avg < max in same color as a diagram line.

CPU2 min  > avg < max in same color as a diagram line.

RAM min  > avg < max  in same color as a diagram line.

Triggered scenes total in same color as a diagram line.

Most triggered scene ID  and scene's name in same color as a triggered scenes

In case dead devices have found during the monitoring period, the time stamp where it happened will colored red and at the top of the screen, directly above the time stamp, dead device(s) ID displayed.

Axis Y has two scales. Left scale  represents occurrence numbers of Z-wave events and triggered scenes. Right scale is a percentage and it related to CPU1, CPU2 and RAM measured values.

By hovering mouse on diagrams or legend, selected item will emphasized in bold to make the item more visible.

I'm strongly advising to use global variable and to view the data using Z-wave Viewer in parallel to Z-wave Monitor

The idea behind, that you can change parameters to view different devices/scenes on the fly.

By changing user configurable parameters in Z-wave Monitor you'll need to start the scene all over again.

Note:

The debug text of these scenes is very big, so If you're using Clear Debug scene, please remove these scenes from the list.

 

Please let me know if extra info is required.

Please report if any bug occurred.


What's New in Version 3.0   See changelog

Released

Bug fix:

1. System reboot initializes Zwave global variable to blank.

 

New features:

Added monitoring of "hidden" communication for repeated,report and pooling Zwave traffic.

The data displayed as "rpt", new column in table

Repeated traffic, means that the user code sends same command over and over to device. In this case device broadcasts back with report status of all his logical endpoints and creates unnecessary load on Zwave traffic. ( Please see Reduce Ztraffic  file at download center https://forum.fibaro.com/files/file/246-reduce-ztraffic-fibaro_call/ ).

Added monitoring of failed communication packets between device and controller (Transfer failed). The data displayed on the table at " nack " new column. This data implies on bad communication to device due to range or something blocks the Zwave ( like walls).

 

Added at end of the table summary of prt and nack measurements



User Feedback

Recommended Comments



Guest amilanov

Posted (edited)

35 minutes ago, cag014 said:

@amilanov

Do you use Fibaro dimmer to dim the light?

 

Yes, and I recall Fibaro releasing commands to send to the dimmer to dim, but they didn't have the functionality that I needed. I'm going to dig up the email I sent to them at the time and post it here....

 

This is the exact email I sent on 22nd December 2016:

"

XXXXX,

 

I was very excited to try the following functions and am now sharing my feedback, sorry to say they did not live up to the excitement:

- fibaro:call(ID, 'startLevelIncrease', x, y)

- fibaro:call(ID, 'startLevelDecrease', x, y)
- fibaro:call(ID, 'stopLevelChange')
 
a) 'startLevelIncrease' appears to increase from a low dim value (close to zero) to the set value which is fine, but when I look at the web interface the device brightness level never changes and when I query the brightness level using lua e.g. fibaro:debug(fibaro:getValue(295, "value")), the level never changes from what it was before I run the function e.g. 
1. actual dim brightness = 60
2. run fibaro:call(295, 'startLevelIncrease', 10, 100)
3. dim brightness queried within 10 seconds always reports = 60
4. dim brightness after 10 seconds still reports = 60
5. dim brightness on web interface shows = 60
This alone makes the function of no use. If the value of the device shows as being exactly the same before and after the function has been run and yet the light level has changed, then I can't use this.
 
b) 'startLevelDecrease' appears to run from the set value e.g. fibaro:call(295, 'startLevelDecrease', 10, 50) to something close to zero, but it doesn't turn the light off. I am not sure how to use the function if it never turns the light off. As with 'startLevelIncrease' the brightness level never changes on the web interface or via lua query
 
c) The idea of the above functions is great and I guess the developers were limited in what they could do, but I have to share my 2 cents worth:
1. startLevelIncrease should be: fibaro:call(ID, 'startLevelIncrease', time in seconds, start value, end value) i.e. you should be able to specify the start and end value to increase to. The same should go for decrease, in which case there would be no need for 'stopLevelChange'
2. quite obviously the values of the devices have to change to reflect the actual value of the light, otherwise the functions are of no use
3. if startLevelDecrease never turns the light off, I am not sure how it is to be used
 
I hope you have a Merry Christmas!!
 
Regards
Aleks"

 

 

 

Edited by amilanov
Link to comment
Share on other sites

Guest cag014

Posted (edited)

As far as I know there is a parameter to set time for single step... somthing like that.

In this case when you send turnOff or turnOn this could be done accroduing to time step.

In my bedroom I have set time step that overall it takes around 20 seconds to turnOff or ON  the light, it's exactly the effect that you're looking for and it just one command

Have found it

Spoiler

Capture.thumb.PNG.559d7802a2a10a267eaf64688087def3.PNG

 

Edited by cag014
Link to comment
Share on other sites

1 minute ago, Momos said:

softly dim lights :D. I don't soft dim, just dim and get it over with :P. 1 command

 

That explains a lot... I was doing a very majestic soft dim, but it's now a little more abrupt. 

 

Turning lights straight off doesn't work well on the off chance that you are still in the corridor or room when they start to dim.

 

By dimming down softly you have a chance to wave your hands around and keep the lights on.... admittedly after tweaking my "on time" per zone, this rarely happens, but it did the other night when I had guests leaving and I was standing in the corridor when the lights started to dim down. I couldn't set my scenes to go straight off. It's too much of a sacrifice on functionality for me.

 

 

Link to comment
Share on other sites

never said anything about dimming to off. i dim to like 15-20% then after a sleep time to off. Network has no load this way. I usually prefer to keep it as simple as possible to avoid any complications.  And my "on time" per zone is big enough, don't mind the extra watts consumed as long as system runs smooth :)  

But i don't do gradual dimming like every 5%, its useless imo.

Link to comment
Share on other sites

8 minutes ago, cag014 said:

overall it takes around 20 seconds to turnOff or ON  the light

 

That's not how I want my lights to work.


When I turn a light on from a wall switch it should turn on immediately 

When I turn a light off from a wall switch it should turn off immediately - well it can fade out for a couple of seconds max

 

When lights turn on from automated light they should turn on immediately

When lights turn off from automated light they should dim down slowly over a period of time - I have set this to 60 seconds for all my lights

Link to comment
Share on other sites

20 minutes ago, amilanov said:

but they didn't have the functionality that I needed.

 

I wrote this test script in 2017 and it indeed uses startLevelIncrease. I don't actually use it but I remember writing this script to better understand how it works. As far as I remember, it can do smooth up and down dimming but I never actually used it in production.

 

It sends only a single Z-Wave command (per call), the dimming is done by the device and requires no Z-Wave packets.

 

ID = 415
function exec(cmd, time, sleeptime, startlevel)
  print(string.format("Calling \"%s\" with time = %d, startlevel = %s. "..
      "Then sleep for %d seconds.", cmd, time, startlevel, sleeptime))
  fibaro:call(ID, cmd, time, startlevel)
  fibaro:sleep(sleeptime*1000)
  print("Done sleeping")
end
exec("startLevelIncrease",10,15,0)
exec("startLevelDecrease",10,15)

exec("startLevelIncrease",10,6)
exec("startLevelDecrease",10,4)
-- Cleanup to finish
fibaro:call(ID, 'stopLevelChange')
fibaro:sleep(2000)
fibaro:call(ID, 'turnOff')

 

  • Like 1
Link to comment
Share on other sites

Guest amilanov

Posted (edited)

11 minutes ago, Momos said:

never said anything about dimming to off. i dim to like 15-20% then after a sleep time to off. Network has no load this way. I usually prefer to keep it as simple as possible to avoid any complications.  And my "on time" per zone is big enough, don't mind the extra watts consumed as long as system runs smooth :)  

But i don't do gradual dimming like every 5%, its useless imo.

 

You beat me to it. I wrote my automated lighting scenes back in 2014. 


 

33 minutes ago, amilanov said:

This is the exact email I sent on 22nd December 2016:

 

I looked back at my email I sent to support back in Dec 2016, you can see the email a few posts above, and I realised that even though the commands were buggy back then (and didn't work) that they probably work just fine now. 

 

Looks like I'll be updating my auto lighting scene sometime soon (tonight :) ) to use "startLevelDecrease" 


Thanks for your help guys!!!! 

 

I wouldn't have and didn't pick this up until now. 

 

I wonder what other lovely little tricks I've been missing out on over the past years of not being active on the site....

 

 

 

8 minutes ago, petergebruers said:

I wrote this test script in 2017 and it indeed uses startLevelIncrease. I don't actually use it but I remember writing this script to better understand how it works. As far as I remember, it can do smooth up and down dimming but I never actually used it in production.

 

It sends only a single Z-Wave command (per call), the dimming is done by the device and requires no Z-Wave packets.

 

Thanks. I'm on it now :) 

Edited by amilanov
Link to comment
Share on other sites

5 minutes ago, amilanov said:

I wrote this test script in 2017

 

Typo in my original post. I wrote my email to tech support in 2016 not 2017.

Link to comment
Share on other sites

I do not follow you guys, you suggest to send 6 commands to dim the lights when there is a same built-in functionality?

You have two options, Automatic and Manual., meaning automatic (z-wave) could dim slowly the lights  and manual could work immediately .

I have 6 dimmers, so don't understand me wrong,  I'm just trying to understand the benefit of using this procedure.

Link to comment
Share on other sites

2 minutes ago, cag014 said:

do not follow you guys, you suggest to send 6 commands to dim the lights when there is a same built-in functionality?

 

I don't follow what you are saying. I wrote to @petergebruers saying that I was going to implement "startLevelDecrease" in my code.

 

I'm not implementing what he wrote. I need something bespoke for my automated lighting scene.

 

I will now send 1x command to turn lights on, 1x command to dim lights down and 1x command to turn the lights off - this is 3x commands per light per cycle from on to fully off. 

 

 

 

 

Link to comment
Share on other sites

Guest amilanov

Posted (edited)

 

@cag014

I do have a question for you... which devices support "startLevelDecrease"?

I just realised that I am implementing it on all my lighting, but I may need extra conditions.

 

I have Fibaro dimmer 1, Fibaro dimmer 2 and Fibaro RGBW for lighting.

I have Fibaro relays, but I deal with them separately already.

 

I'm scouring the forum, but figure you may know off the top of your head... or maybe someone else does?

EDIT: I found a post that says it is supported on dimmer2, rgbw and roller shutter. I assume it is supported on dimmer 1 as well:

 

Edited by amilanov
Link to comment
Share on other sites

Try

fibaro:debug(json.encode(fibaro:getDevicesId({interfaces = {"levelChange"}})))


you should receive list of IDs with ' startLevelDecrease ' functionality.

Link to comment
Share on other sites

Guest amilanov

Posted (edited)

12 minutes ago, cag014 said:

fibaro:debug(json.encode(fibaro:getDevicesId({interfaces = {"levelChange"}})))


Very slick. Thanks!

 

I'm going to call it a night.... whatever parm I set my dimmer 1 (which appears to support the startLevelDecrease) dims down in a few seconds every time.  No idea what's going on.

 

fibaro:call(586, 'startLevelDecrease', {time to dim], [start level])

 

I've tried time in seconds and milliseconds... doesn't seem to change a thing.

I've left [start level] blank and filled it ... doesn't seem to change a thing.

 

@T.Konopka

 

Can you please move my posts about "startLevelDecrease" to a new thread?

I don't know how to do this or if I can do this myself. 

Thanks!

 

Edited by amilanov
Link to comment
Share on other sites

The script I posted works on my dimmer 1, see a few posts back, I have tested it.

 

This will dim up from the current level to 100% in 10 seconds:

fibaro:call(ID, "startLevelIncrease", 10, fibaro:getValue("vaule",ID))
or simply
fibaro:call(ID, "startLevelIncrease")

And this down from current level to 0 (or lowest setting of your dimmer, see parameters):

fibaro:call(ID, "startLevelDecrease", 10, fibaro:getValue("value",ID))
or simply
fibaro:call(ID, "startLevelDecrease", 10)

EDIT: sorry, I realized I was very unclear. What I wanted to show is that the last parameter is (a) optional and  defaults to "the last set level) (b) the paramter is the start level not the end level. 

 

According to the Z-Wave spec the time is encoded an uses 8 bits...

 

0 = instantly

0 - 127 = duration in seconds

128-254 = duration in minutes

255 = factory default duration.

 

I'v never tested anything in minutes...

 

As you can see... there is no target level so it is always going to 0 or 100%. That is what I use "stopLevelChange" for. And that is probably the reason why I never use this in production. It might be useful though to assign one button on a remote to "increase" and another one to "stop" (instead of using direct association eg on a Fibaro Keyfob)

 

The Z-Wave spec says all devices supporting Multilevel Switch CC, version 2 or higher should work, some manufacturers put this info in their manual and you can check the official Z-Wave db. "A device supporting Multilevel Switch CC, version 2 MUST support Multilevel Switch CC, version 1. Version 2 adds a “Duration” parameter to the Multilevel Switch Set and Multilevel Switch Start/Stop Level Change commands."

 

 

Edited by petergebruers
Link to comment
Share on other sites

When you run monitor,  script creates global variable "zwave_scenedID". On my system it is "zwave_571"

Created name displayed on debug window

Spoiler

zwave.PNG.6bf13ef5f4f1b48a0a09bbda5709ec24.PNG

 

Please update gVarName in viewer to your global name.

Spoiler

zwave.PNG.03a7fab3ad2ead8ccd36598f16265f6d.PNG

 

Link to comment
Share on other sites

I have managed to fix my variable issue and generate a detailed report of my system. I think I have a lot of traffic which could be overloading the system and causing the crashes. a good clean up might give me a much better system. Would really appreciate the feedback to see how these crashes can be fixed

 

Thanks

 

 

Screenshot 2019-06-24 at 12.54.16.png

Screenshot 2019-06-24 at 12.54.29.png

Screenshot 2019-06-24 at 12.54.39.png

Screenshot 2019-06-24 at 12.54.51.png

Screenshot 2019-06-24 at 12.55.02.png

Screenshot 2019-06-24 at 12.55.11.png

Screenshot 2019-06-24 at 12.55.21.png

Screenshot 2019-06-24 at 12.55.30.png

Screenshot 2019-06-24 at 12.55.38.png

Link to comment
Share on other sites

Guest cag014

Posted (edited)

Doesn't make sense.... cycle rate defined by logRate global variable in minutes

logRate = 2      -- Time rate in minutes to log Z-wave activity.

If it runs for two days, what your  time2monitor set to?
time2monitor = 6     -- Time-slot in hours to monitor z-wave traffic.

Could you please post your global variables definition?

Another question, where you see this message (Z-wave monitor or viewer)?

Edited by cag014
Link to comment
Share on other sites

I may have missed some settings... This is what I see in Viewer:

 

image.png.d60fdcc82e9c189f61ba1727d588ec4f.png

 

And this is the debug window of Monitor:

 

[DEBUG] 15:54:11: Z-wave monitoring has started for next 6:00:00 hour(s).
Created new predefined global variable
zwave_84

 

Code window of Monitor:

gVar = true              -- Create and use global predefined variable (to keep history)
logRate = 1      -- Time rate in minutes to log Z-wave activity.
time2monitor = 6     -- Time-slot in hours to monitor z-wave traffic.

 

Sorry, I'm not too familiar with scripting. Thanks for your help!

Link to comment
Share on other sites

51 minutes ago, johndeere said:

I may have missed some settings... This is what I see in Viewer:

 

image.png.d60fdcc82e9c189f61ba1727d588ec4f.png

 

And this is the debug window of Monitor:

 

[DEBUG] 15:54:11: Z-wave monitoring has started for next 6:00:00 hour(s).
Created new predefined global variable
zwave_84

 

Code window of Monitor:

gVar = true              -- Create and use global predefined variable (to keep history)
logRate = 1      -- Time rate in minutes to log Z-wave activity.
time2monitor = 6     -- Time-slot in hours to monitor z-wave traffic.

 

Sorry, I'm not too familiar with scripting. Thanks for your help!

That's interesting...

Looks like you don't have any Z-wave traffic!? How many devices you have?

Please try to set logRate to 3 minutes.

Link to comment
Share on other sites

What do you mean by corrupted?  What version your system on?

Please update to latest version...

Link to comment
Share on other sites


Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...