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 cag014

Posted (edited)

@johndeere

Please download attached file.

Pay attention the file doesn't include user configurable parameters portion, so please copy to your scene from follow line to end

--========================== Please do not change parameters below ===============================================

 

Let me know when you downloaded the file. I want to remove this copy from forum to avoid beta version spreading.

 

 

Edited by cag014
Link to comment
Share on other sites

1 hour ago, cag014 said:

@johndeere

Please download attached file.

Pay attention the file doesn't include user configurable parameters portion, so please copy to your scene from follow line to end

--========================== Please do not change parameters below ===============================================

 

Let me know when you downloaded the file. I want to remove this copy from forum to avoid beta version spreading.

 

Z-wave Monitor-v3.1.lua 45.55 kB · 1 download

I have downloaded it. Thank you very much! :)

Link to comment
Share on other sites

16 hours ago, cag014 said:

Thanks for prompt response

This is what it shows now:

image.png.7f23e8e6eceb7933c86f064f69ef2292.png

 

Since I don't have anything to compare it with, I'm asking if you think the failed transfers are too high or normal...?

Link to comment
Share on other sites

Huge... it should be around 5%. In your case it's over 50% percent of Zwave communication.

 

Link to comment
Share on other sites

52 minutes ago, cag014 said:

Huge... it should be around 5%. In your case it's over 50% percent of Zwave communication.

 

Hmm... Something must be wrong with my whole Z-wave routing. I went around the house and breached all sensors.

 

image.png.2a2ba479b37a0cbb281e18c0f585907b.png

 

Is that 65% which shows the fail percentage?

 

Interesting: one sensor is stuck again in breached status, but it does not appear in the red "nack" column... It should appear, shouldn't it?

Edited by johndeere
Link to comment
Share on other sites

Yes... it is. It shows that you have too many reports from device(s). I mean in some devices the factory default set to send reports every few seconds or power measurements reacts to very small changes.

Transfer failed looks too high also. Probably some devices is too far (or blocked by walls) from HC2 and time to time the commands didn't get trough.

 

I would like to suggest you to download All-in-One Scene to control your events.

The reason I suggest to use it, that this scene always monitors Zwave traffic ( total, failed and dead events) in addition to many other information.

It will keep you aware about all necessary information on demand.

Link to comment
Share on other sites

OK. Tomorrow I will do the All-in-One. I am at the system only during working hours. Thank you for the feedback and suggestions.

I have walls, yes, but I also have repeaters. Looks like some sensors are trying hard to avoid repeaters. This is not normal Z-wave networking...

 

In HC2 in Z-Wave menu there are some options: reconfigure all devices again, reset z-wave... If I have to do the whole setup from scratch again... I don't know.

 

Do I have to stop this monitor scene or can I let it as is?

 

 

Link to comment
Share on other sites

Yes, you can stop it. In future you always can take a look on that by Z-wave viewer.

Please pay attention to devices that failed, they should be listed in the table. Verify if these devices cause any problems, like delays or shown dead occasionally. See if you can improve somehow  their location, sometime just to move a little bit the device could improve communication.

I strongly do not suggest to reset z-wave. It won't help and creates endless setup.

In addition please check parameters setup of top active device that shown in Z-wave monitor.

Link to comment
Share on other sites

4 hours ago, cag014 said:

Please pay attention to devices that failed, they should be listed in the table.

I watched a motion sensor which was stuck in breached status for 20 minutes, but it did not appear in the "nack" column... After about an hour the sensor managed to switch back to normal (safe) status by itself. How much time does this monitor script wait until a red number appeares in the nack column?

4 hours ago, cag014 said:

See if you can improve somehow  their location, sometime just to move a little bit the device could improve communication.

This is why repeaters are for... I will include more repeaters, but my experience is, that sensors don't really give a sh*t on repeaters, even after several mesh reconfigs. At least in my case.

4 hours ago, cag014 said:

I strongly do not suggest to reset z-wave. It won't help and creates endless setup.

Thank you for this, you saved me a lot of potentially wasted time! :)

4 hours ago, cag014 said:

In addition please check parameters setup of top active device that shown in Z-wave monitor.

OK, I will. However I cannot change parameters on many devices, because my "wait for sync" issues, soft reconfig problems, etc. Fibaro is working on this problem too.

 

Thanks for all!

 

 

Link to comment
Share on other sites

23 minutes ago, johndeere said:

I watched a motion sensor which was stuck in breached status for 20 minutes, but it did not appear in the "nack" column... After about an hour the sensor managed to switch back to normal (safe) status by itself. How much time does this monitor script wait until a red number appeares in the nack column?

Based on my experience HC2 didn't receive the state change from the sensor, so  "nack" didn't happen. It will be updated with correct status during wake-up.

Link to comment
Share on other sites

17 minutes ago, cag014 said:

Based on my experience HC2 didn't receive the state change from the sensor, so  "nack" didn't happen. It will be updated with correct status during wake-up.

It does not sound good. If the HC2 did not receive status change because of low signal, or out of coverage (which is not the case here), then what is the guarantee that it will receive it when wake-up?

It happened many times before, that I armed the system, then after an hour HC2 received the breached status report and the alarm went off, causing a false alarm.

Anyway, I will go with more repeaters.

 

Link to comment
Share on other sites

Guest cag014

Posted (edited)

Since you already have repeaters which didn't help (as you said), if you have any spare Zwave main powered device (not battery operated) try to connect it instead of repeater (at same physical place) . It should work as repeater, just to make sure that repeater work correctly

 

Edited by cag014
Link to comment
Share on other sites

36 minutes ago, cag014 said:

Since you already have repeaters which didn't help (as you said), if you have any spare Zwave main powered device (not battery operated) try to connect it instead of repeater (at same physical place) . It should work as repeater, just to make sure that repeater work correctly

 

 

What I mean by repeater are all my devices which are constantly powered: from mains (UPS) or 12V (UPS) so that power outage is not a problem.

However there is one AoT range extender, which seems to work, but it has no traffic record in your monitor script...

Link to comment
Share on other sites

1 minute ago, johndeere said:

 

What I mean by repeater are all my devices which are constantly powered: from mains (UPS) or 12V (UPS) so that power outage is not a problem.

However there is one AoT range extender, which seems to work, but it has no traffic record in your monitor script...

By main power, I meant not battery operated devices (they don't used in mesh route by definition)

Range extender just transferring the data back and fourth from other devices... no direct communication.

Link to comment
Share on other sites

2 minutes ago, cag014 said:

By main power, I meant not battery operated devices (they don't used in mesh route by definition)

Range extender just transferring the data back and fourth from other devices... no direct communication.

Yes, I understand. I use e.g Fibaro wall plug, relay switch, garage door controller - all are non-battery operated.

Speaking about the range extender, this one has features which work with direct communication. Tomorrow I will dig deeper on this.

 

Thanks :)

 

Link to comment
Share on other sites

@johndeere you are wasting your time. Only Zniffer can help you. With Zniffer you will understand routing and repeaters and why it does not work the way you think it does. Everything else is a complete waste of time (trying to move things, discussions with support, trying to get failed reconfigures to run again, staring at this monitor tool, ...)

Link to comment
Share on other sites

5 hours ago, petergebruers said:

@johndeere you are wasting your time. Only Zniffer can help you. With Zniffer you will understand routing and repeaters and why it does not work the way you think it does. Everything else is a complete waste of time (trying to move things, discussions with support, trying to get failed reconfigures to run again, staring at this monitor tool, ...)

Dear Friend, I appreciate your opinion and comment, you may be right. I have already been wasting a lot of my time since I decided to go for Z-Wave, and purchased a lot of devices, without experience in this "beta" or "work-in-progress" technology, as I call it now. However, I feel that my problem is not strictly related to Z-wave technology, but to the software or whatever controls the Z-Wave controller chip. As you see I'm not an expert, but I think with the help of these scripts if I can get a look inside of HC2, and I may get some more information on what was corrupted in my system during that unfortunate "recalled update". The majority of my problems is software related, I'm afraid.

I will go for Zniffer after my system software works as expected - or as advertised :)

The tutorial you kindly suggested, also mentioned these scripts. So I'm just goind that way. These are available rightaway, I can get help, support, the other guys here are also kindly helping me :) It also takes time too, I know...

 

As far as I realized, Zniffer is not an out of the box product - but please correct me if I'm wrong. I will buy on ebay a Z-wave.me stick, wait 2 weeks for delivery, then hack it, and learn it... Sounds fun, but in the meantime I can learn from these scripts. By the way, is there any good Zniffer forum where I can get support?

Thanks again :)

 

Edited by johndeere
Link to comment
Share on other sites

30 minutes ago, johndeere said:

Dear Friend, I appreciate your opinion and comment, you may be are right.

I am, I know because I've tried to help about 20 users with sever issues, and the happy ones are those that own a Zniffer

 

30 minutes ago, johndeere said:

I have already been wasting a lot of my time since I decided to go for Z-Wave, and purchased a lot of devices, without experience in this "beta" or "work-in-progress" technology, as I call it now.

Yeah, you got "bitten" by something and luckily most users don't have a similarly bad experience, but that does not help you...

 

30 minutes ago, johndeere said:

However, I feel that my problem is not strictly related to Z-wave technology, but to the software or whatever controls the Z-Wave controller chip

Correct, can be a combination of both. If you write a script and do 1000 x "turn On" then for sure that kills your network for a short while. I think that counts as a user error but I am not sure, did anybody tell you not to do that? I don't think so... Anyway, you are stumbling in the dark because of lack of diagnostic tools.

 

30 minutes ago, johndeere said:

but I think with the help of these scripts if I can get a look inside of HC2

That is only 1/2 of the picture. A controller chip hides lots of things so if it is not there, HC2 cannot show it to you.

Zniffer shows the complete picture

 

30 minutes ago, johndeere said:

The majority of my problems is software related, I'm afraid.

To a certain extent, and with some effort, we can verify that.

 

Disable all scenes... In all main loops of VD put "fibaro:abort()" so they do not run any code (mainloop runs every 3 seconds). Now your HC2 is a "dumb remote control"

 

If HC2 can reliable control all your devices, without delays, and if devices report status back reliably and without delays... Then very likely you have a software problem.

 

If you have delays or worse (timeouts) then........

 

30 minutes ago, johndeere said:

I will go for Zniffer after my system software works as expected - or as advertised :)

That sounds backwards to me, Zniffer can tell you Node X sends to Y and how often, so you'll clearly understand what is happening.

You are also debugging your software with Zniffer, take that example of sending 1000 x "turn On" - maybe you had not noticed a typo in a scene?

Zniffer tells you how many retries, how many hops, and how long it took.

 

30 minutes ago, johndeere said:

As far as I realized, Zniffer is not an out of the box product - but please correct me if I'm wrong. I will buy on ebay a Z-wave.me stick, wait 2 weeks for delivery, then hack it, and learn it...

Or Mouser or Digikey. The software tool is an official tool. Take note, it only runs on Windows.

 

Here's some buying advice

 

 

Folow the guide posted here to flash the firmware and you'll be "Zniffing" in 30 minutes

 

 

Edited by petergebruers
  • Thanks 1
Link to comment
Share on other sites

Pressed enter too soon

 

40 minutes ago, johndeere said:

The tutorial you kindly suggested, also mentioned these scripts.

Sure! And I think it is excellent advice to use these tools first. No doubt about that. But do understand that retries, routing, neighbors noise are not "visible" on a HC2. Zniffer is the next, and ultimate level. You have to decide when you no longer make any progress and have to change strategy. I gave a rough estimate in hours, but of course it is a personal thing.

 

BTW did you run "sanity check" to reduce reporting of power plugs and dimmers? That's also a tool which will take you maybe 1-2 hour and you can get some results... 

 

44 minutes ago, johndeere said:

These are available rightaway, I can get help, support, the other guys here are also kindly helping me :) It also takes time too, I know...

Indeed.

 

45 minutes ago, johndeere said:

but in the meantime I can learn from these scripts.

Yes, please look at the code and at the GUI, both are beautiful!

 

45 minutes ago, johndeere said:

By the way, is there any good Zniffer forum where I can get support?

Post your questions on this forum. While Zniffer can tell you everything in great detail, you don't need that, but if you want explanation about the bits and the bytes, a few users can help you. I would say... 80-90% of delays and too much reporting and broken associations and so an can be found simply by looking at the "from" and "to" fields...

There's a screenshot in that topic written by @amilanov

 

  • Thanks 1
Link to comment
Share on other sites

@johndeere I have been thinking..., maybe it sounds as if I am "competing" with @cag014 but that is not the case. In fact, users like @cag014 and @amilanov have been discussing HC performance issues for a very long time, we know and understand each other well... It is a private discussion for many reasons, one is we "dig deep" and that cause a lot of tech geek noise... The post by Amilanov is the culmination of a lot of hard work by many contributors. All having 100 or more physical nodes...

  • Like 1
Link to comment
Share on other sites

33 minutes ago, petergebruers said:

 

I appreciate your time and energy you spent on your detailed reply, thank you. ?

Let's suppose I already have that wonderful detailed data you can get from zniffer. I see that a bunch of retries, unsuccessful transmissions, etc are revealed.

What then? Is there any device parameter I can set to PLEASE the device not to go through 5 thick walls, rather to use the repeater which has full signal and is literally stick to it with duck tape?

I don't know any way of manually configuring Z-wave mesh. Zniffer won't be able to cure HC2's buggy mesh redonfiguration... Am I wrong here?

6 minutes ago, cag014 said:

Agree and absolutely correct.

Glad to see you are in the same team :)

Link to comment
Share on other sites

49 minutes ago, johndeere said:

Let's suppose I already have that wonderful detailed data you can get from zniffer. I see that a bunch of retries, unsuccessful transmissions, etc are revealed.

What then? Is there any device parameter I can set to PLEASE the device not to go through 5 thick walls, rather to use the repeater which has full signal and is literally stick to it with duck tape?

Well, first we have to establish that you have this kind of problem, but it is not high on the list of possible problems... Z-Wave routing is not extremely fragile or buggy.

 

But to answer the question... Yes, you could force device X to route through device Y, but then you need a second Z-Wave dongle to send special commands, using a free tool, we are talking geek stuff now.  I have one plug with forced routing. Instead of buying another controller to do that, you can also do things with the HC2 that are way beyond "simply voiding warranty" ;)

 

54 minutes ago, johndeere said:

Zniffer won't be able to cure HC2's buggy mesh redonfiguration... Am I wrong here?

Zniffer can tell you if HC2 asks the device to update neighbors. If you see no such packet, HC2 is not doing the right thing. Exclude and include...

If you see it asks the device... Zniffer will tell you if the device scans its neighbors, and posts back the results. You might learn that it is too far away, or does not respond, so again probably exclude and include and move and mesh reconfigure. You may think... I don't need Zniffer to do that "dance"... But you'll know what is happening and avoid trying something X times without getting any different result.

 

People have found all kinds of weirdness... Like setting some parameters to "0" and expecting the reporting to stop. In some cases, quite the opposite happens: the device starts sending like crazy.

 

If you have the old Fib RGBW, and did not update to firmware 2.7, you may see it send packets to non-existent devices.

 

You may notice, a laptop charger in Wall Plug causes it to send 5 power updates per minute, which take a bit of bandwidth, make scenes run without cause, and fill your history with garbage data only to slow down your database. HC2 flash write performance is not like that SSD in your PC...

 

Some of these issues are caught by the tool @cag014 probably the last one, but not those special cases.

 

You know, I am going to state the obvious... If you do not make any mistakes, and you set all reporting to sane values, and your HC2 does not crash like yours did... It is possible to run a 100 node network with satisfactory results. But it depends a bit on your expectations, Z-Wave is not fast, if you expect 10 devices to turn instantly, that is not going to happen.

 

Again... Zniffer will tell if device X has a direct connection, in that case it takes 20 ms to control. If it is routed, one hop, it takes about 50-60. Multiply by 10... And I am being optimistic, not counting overhead and recommend actually to slow down things...

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...