I have two Zwave devices, both Aeotec Smart Switch 6 and Smart Switch 7, receptacles.

The Smart Switch 7 receptacle connects to ISY but I cannot get it to self update the energy monitor. This is the same as the 12 series 3 receptacles I have. No those are not in my system right now, and do not exist in polISY. The only way to update the energy monitor is to poll the device.

The Smart Switch 6 receptacle cannot be found with polISY at all. The information on both devices is very sketchy but the user guide tells how to connect with security and without. I have tried both. The active and included Smart Switch 7 device is about 4 feet from the series 6 device.

One other thing. WTF are all these nodes and duplicate nodes doing in ISY??? This appears like some device that is not fully developed in ISY yet. Looks like a mess.

Any tips to what is going on with these devices? Do any Zwave devices self update ISY or do they all have to be polled for secondary nodes?? If that is true  I could have stuck with much cheaper series 3 devices?

Edited January 27, 20223 yr by larryllix

Perhaps the SiLabs Seres 700 dongle is causing me incompatibilities with polISY v5.3.0?
 

Anybody else tried these Aeotec Energy Monitor receptacles with their ISY? Do they ever report the energy status or do they have to be polled?

Edited January 26, 20223 yr by larryllix

@larryllix,

You need to set the parameters to real time updates. You need to look at their specs:
Engineering Sheets (PDF Downloadable) : Aeotec Help Desk (freshdesk.com)

With kind regards,
Michel

20 hours ago, Michel Kohanim said:

@larryllix,

You need to set the parameters to real time updates. You need to look at their specs:
Engineering Sheets (PDF Downloadable) : Aeotec Help Desk (freshdesk.com)

With kind regards,
Michel

Other than the options indicated in my post above screenshot , I can't find any mention of any such option. Is there some particular place to look for this option?

The Smart Switch 6 receptacle cannot be recognised by ISY v5.3.0p, at all. I wonder if I have a defective receptacle that cannot introduce itself? I have tried the single click as well as the double click with both ISY's Find and Remove Zwave devices and no response is ever seen in the admin console.

ENERGY METERING UPDATE
Looks like I have to set parameters by parm numbers. Is this a preliminary setup? This is very user unfriendly. Will parm field names be coming later?
It appears I need to set thresholds and update times manually, more sensitive and faster when expected usage is happening, and then slow things down when not (to avoid data storms on ISY).  It appears energy monitoring is expected to be a low priority mission in the Smart Switch 7 with lack of intelligent updating.
Smart Switch 6 is still ignored by ISY still.

Edited January 27, 20223 yr by larryllix

4 hours ago, larryllix said:

Other than the options indicated in my post above screenshot , I can't find any mention of any such option. Is there some particular place to look for this option?

The Smart Switch 6 receptacle cannot be recognised by ISY v5.3.0p, at all. I wonder if I have a defective receptacle that cannot introduce itself? I have tried the single click as well as the double click with both ISY's Find and Remove Zwave devices and no response is ever seen in the admin console.

ENERGY METERING UPDATE
Looks like I have to set parameters by parm numbers. Is this a preliminary setup? This is very user unfriendly. Will parm field names be coming later?
It appears I need to set thresholds and update times manually, more sensitive and faster when expected usage is happening, and then slow things down when not (to avoid data storms on ISY).  It appears energy monitoring is expected to be a low priority mission in the Smart Switch 7 with lack of intelligent updating.
Smart Switch 6 is still ignored by ISY still.

Of you're close to your polisy with your device and it won't remove, then it's probably a defective device. Regardless of whether a controller can recognize a device, any controller can complete the remove process. 

Theres no way to set parameter names. Every manufacturer use their own parameters. This isn't defined by the zwave alliance.  On top of that, different devices can use the same parameters as other device types but do something completely different. Welcome to the world of zwave

6 hours ago, larryllix said:

Looks like I have to set parameters by parm numbers. Is this a preliminary setup?

Yes, that's what I was suggesting.

With kind regards,
Michel

4 hours ago, Michel Kohanim said:

Yes, that's what I was suggesting.

With kind regards,
Michel

Thanks! I thought the Zwave devices GUI would be more polished at this point. This is a PITA sooooo...

Looks like the answer is more ISY constants, unless UDI is going to make more detailed parameter descriptions but I assume it is different for every brand and model anyway.

We need a admin constant variable pocket with another pulldown menu for variable selection separate from constants please......... (I have over 500 variables now that make ISY living much easier.. )

For those of you not variphobic, here is the ISY variable constant technique I use, to avoid not having to find and review  technical docs every time I want to edit a program.
Note: The ending "1B" and "2B" specifies the length of the parameter field required.
          These parameters have not been tested to this point yet.

Washer Sensitize - [ID 0122][Parent 0066]

If
   - No Conditions - (To add one, press 'Schedule' or 'Condition')
 
Then    
        // Set internal check time
        Set 'WashMach Switch' Set Configuration Parameter '$cPARM.CHECK.TIME_1B' = 5   
        // Set Watts & Amps threshold=0, update time=30s
        Set 'WashMach Switch' Set Configuration Parameter '$cPARM.WATT.THRESHOLD_2B' = 0
        Set 'WashMach Switch' Set Configuration Parameter '$cPARM.WATTS.TIME_2B' = 30
        Set 'WashMach Switch' Set Configuration Parameter '$cPARM.AMPS.THRESHOLD_1B' = 5
        Set 'WashMach Switch' Set Configuration Parameter '$cPARM.AMPS.TIME_2B' = 0
        Set 'WashMach Switch' Set Configuration Parameter '$cPARM.VOLTS.TIME_2B' = 0
        Set 'WashMach Switch' Set Configuration Parameter '$cPARM.KWH.TIME_2B' = 0
        Set 'WashMach Switch' Set Configuration Parameter '$cPARM.KWH.THRESHOLD_2B' = 0
        Set 'WashMach Switch' Write Changes    
        // 
        Wait  10 minutes 
        Run Program 'Washer Desensitize' (If)
 
Else
   - No Actions - (To add one, press 'Action')
 

 

 

 

On 1/27/2022 at 1:31 PM, larryllix said:

unless UDI is going to make more detailed parameter descriptions but I assume it is different for every brand and model anyway

These are called Manufacturer Specific parameters. It would be impossible for us to map 1000s of manufacturer specific parameters and keep them up to date.

With kind regards,
Michel

5 hours ago, Michel Kohanim said:

These are called Manufacturer Specific parameters. It would be impossible for us to map 1000s of manufacturer specific parameters and keep them up to date.

With kind regards,
Michel

I assumed the basic parameters to make them function would have been incorporated into the GUI and not 2-3 duplicates of everything, including  detailed pulldown menus that control a coloured LED on the side of the box, nobody will ever see.

10 hours ago, larryllix said:

I assumed the basic parameters to make them function would have been incorporated into the GUI and not 2-3 duplicates of everything, including  detailed pulldown menus that control a coloured LED on the side of the box, nobody will ever see.

You assumed wrong. Zwave alliance does not define that information.There are no such thing as basic Parameters. Any that you see is what the mfg. decided on. It's easy to research to see for yourself. Take a look at old and new Jasco/GE manuals. You'll see some of the same parameters doing different things for like devices. Ditto for fibero and aeotech

seems the more I learn about z-wave devices the more I appreciate Insteon devices.

2 hours ago, mmb said:

seems the more I learn about z-wave devices the more I appreciate Insteon devices.

I am not sure this is only Zwave things. I am a newbie to this realm also but the GUI for this device is only half baked.
Cripes we don't have to insert hexadecimal field numbers for any Insteon devices and I know they don't talk in English names fields. Why would UDI leave these devices at the low level a hexadecimal programmer level. This will turn users off and get them to go elsewhere. I just figured the time was early but if all Zwave devics are left for the user to research technical manuals to find the necessary hexadecimal field numbers, ISY will be dead in a year or two.

I mean really? How many users will use lines like this to turn on the reporting of the basic metering?

Set 'WashMach Switch' Set Configuration Parameter 0x1B = 0

...and then they must know the bit length of the parameter field to communicate properly.

How many ISY users will understand what "unsigned binary" or 0x1B means in order to use a Smart Receptacle?

Am I missing something here? Was my response from @Michel Kohanim confused somehow? If this is a temporary solution for so many Zwave devices, without studying every engineering manual (a daunting task), will there come a time where knowledgeable users can submit real names for fields on Zwave devices for ISY users that are even afraid of using variables, because they are "too complicated"?

 

Edited January 29, 20223 yr by larryllix

5 minutes ago, larryllix said:

I am not sure this is only Zwave things. I am a newbie to this realm also but the GUI for this device is only half baked.
Cripes we don;t have to insert hexadecimal field numbers for any Insteon devices and I know they don't talk in English names fields. Why would UDI leave these devices at the low level a hexadecimal programmer level. This will turn users off and get them to go elsewhere. I just figured the time was early but if all Zwave devics are left for the user to research technical manuals to find the necessary hexadecimal field numbers, ISY will be dead in a year or two.

I mean really? How many users will use lines like this to turn on the reporting of the basic metering?

Set 'WashMach Switch' Set Configuration Parameter 0x1B = 0

...and then they must know the bit length of the parameter field to communicate properly.

How many ISY users will understand what "unsigned binary" or 0x1B means in order to use a Smart Receptacle?

Am I missing something here? Was my response from @Michel Kohanim confused somehow?

 

This is one of the major drawbacks to z-wave. Each manufacturer is free to implement things as they see fit. In order to convert these parameters into readable menu options would require a team of people just inputting the information. This is one of the big reasons why I believe in documentation of everything. Once you get out of the Insteon only realm things can get very tricky, very quickly. You really need to plan out ahead and have an idea of the technical aspects before you even buy. This is very much at odds with the buy an Insteon device and just know it will work.

 

My advice to UDI would be to harness this community to start to buildout a database of these parameters.

JMHO

7 minutes ago, ase said:

This is one of the major drawbacks to z-wave. Each manufacturer is free to implement things as they see fit. In order to convert these parameters into readable menu options would require a team of people just inputting the information. This is one of the big reasons why I believe in documentation of everything. Once you get out of the Insteon only realm things can get very tricky, very quickly. You really need to plan out ahead and have an idea of the technical aspects before you even buy. This is very much at odds with the buy an Insteon device and just know it will work.

 

My advice to UDI would be to harness this community to start to buildout a database of these parameters.

JMHO

I agree with the user database and made that suggestion a few years ago, also.

However, if the same thing was applied to a Zwave thermostat, the parameter selections done in binary would entail hundred, maybe thousands of fields. People wouldn't love to look up parameter field numbers everytime they wanted to set the HVAC setpoint.

Meanwhile dozens and dozens of field parameter were assigned to predefined fields with predefined pulldown menu selections for the colour RGBW, including the ramping speed of the LED,  the sequencing times for flashing, and effects, for the little LED on the side of the receptacle, which nobody will ever see and only possibly for troubleshooting technical people.

This is how to get non-tech users to run away from ISY and surely must be a mistake somehow.

4 hours ago, ase said:

This is one of the major drawbacks to z-wave. Each manufacturer is free to implement things as they see fit. In order to convert these parameters into readable menu options would require a team of people just inputting the information. This is one of the big reasons why I believe in documentation of everything. Once you get out of the Insteon only realm things can get very tricky, very quickly. You really need to plan out ahead and have an idea of the technical aspects before you even buy. This is very much at odds with the buy an Insteon device and just know it will work.

 

My advice to UDI would be to harness this community to start to buildout a database of these parameters.

JMHO

And who's going to manage this database and the 10s of thousands of parameters that could potentially be out there? Everyone says what UDI should and could do but yet I bet not a single person has looked into seeing what it would take for this to happen. 

How many have taken the time to read up on what it takes to program for zwave or looked deeper into what goes into setting up their device?  

Not even the op took the time to read the manual to see what was going on with his device before posting about his issue. However, he's quick to be on here saying how things should be done. A simple Google search (or owners manual search) on aeotech's website would've provided the answer. But that was too much work.

Yet everyone expects UDI to spend countless time, money and effort to try to program in a database of 10s of thousands of potential parameters for thousands of different devices for something that takes an individual 5 minutes of effort. 

No one wants to do any research or listen to those who has but have all sorts of ideas of what others should be doing (but won't do for themselves).

 

And people wonder why prosumers are being abandoned by companies. They have the most to say but no willingness to take the time to understand things how things work.

Edited January 30, 20223 yr by lilyoyo1

4 hours ago, larryllix said:

I agree with the user database and made that suggestion a few years ago, also.

However, if the same thing was applied to a Zwave thermostat, the parameter selections done in binary would entail hundred, maybe thousands of fields. People wouldn't love to look up parameter field numbers everytime they wanted to set the HVAC setpoint.

Meanwhile dozens and dozens of field parameter were assigned to predefined fields with predefined pulldown menu selections for the colour RGBW, including the ramping speed of the LED,  the sequencing times for flashing, and effects, for the little LED on the side of the receptacle, which nobody will ever see and only possibly for troubleshooting technical people.

This is how to get non-tech users to run away from ISY and surely must be a mistake somehow.

I never took the Isy as a device for non tech users.

The biggest mistake i see people make is not taking the time to read the manual for the devices they are just getting into vs. it being an Isy issue

18 hours ago, lilyoyo1 said:

And who's going to manage this database and the 10s of thousands of parameters that could potentially be out there? Everyone says what UDI should and could do but yet I bet not a single person has looked into seeing what it would take for this to happen. 

How many have taken the time to read up on what it takes to program for zwave or looked deeper into what goes into setting up their device?  

Not even the op took the time to read the manual to see what was going on with his device before posting about his issue. However, he's quick to be on here saying how things should be done. A simple Google search (or owners manual search) on aeotech's website would've provided the answer. But that was too much work.

Yet everyone expects UDI to spend countless time, money and effort to try to program in a database of 10s of thousands of potential parameters for thousands of different devices for something that takes an individual 5 minutes of effort. 

No one wants to do any research or listen to those who has but have all sorts of ideas of what others should be doing (but won't do for themselves).

 

And people wonder why prosumers are being abandoned by companies. They have the most to say but no willingness to take the time to understand things how things work.

 No one suggested UDI maintain the database. A database is very simple each person simply adds the parameters as they find them. This requires zero effort for UDI.

This concept is called crowd souce. It is how many companies support complex products. 

I am personally tempted just to host the database on my servers. 

Further no one has suggested that ISY or Polisy are for non tech people. There are however different levels technical understanding. I don't know your level however, I have written software, designed hardware, administrated networks for f500 companies as well as run my own IT firm. I am willing to bet that I see things very differently than the home grown hobbyist.

I would in fact advocate that professionals install home automation due to the technical and electrical aspects. However, the fact remains that will often not be the case. 

That being the case I believe that professional methods should be taught to those who are looking for guidance. After all the methods are built around safety and future troubleshooting.

Part of providing that support as a community is to build out information for common use by users at all technical levels. 

Nobody expects UDI to step up support, they expect the community to step up, after all they are the ones that derive benefits from it. A community is also an optional thing. The community isn't even just this one, it is people in the home automation community in general. 

A database of z-wave parameters would help all of the different home automation users.

The only real question for me is what format should be used.

2 hours ago, ase said:

 No one suggested UDI maintain the database. A database is very simple each person simply adds the parameters as they find them. This requires zero effort for UDI.

This concept is called crowd souce. It is how many companies support complex products. 

I am personally tempted just to host the database on my servers. 

Further no one has suggested that ISY or Polisy are for non tech people. There are however different levels technical understanding. I don't know your level however, I have written software, designed hardware, administrated networks for f500 companies as well as run my own IT firm. I am willing to bet that I see things very differently than the home grown hobbyist.

I would in fact advocate that professionals install home automation due to the technical and electrical aspects. However, the fact remains that will often not be the case. 

That being the case I believe that professional methods should be taught to those who are looking for guidance. After all the methods are built around safety and future troubleshooting.

Part of providing that support as a community is to build out information for common use by users at all technical levels. 

Nobody expects UDI to step up support, they expect the community to step up, after all they are the ones that derive benefits from it. A community is also an optional thing. The community isn't even just this one, it is people in the home automation community in general. 

A database of z-wave parameters would help all of the different home automation users.

The only real question for me is what format should be used.

The point I was trying to make is why the user has been gifted to use a pulldown menu to turn a Zwave device on and off, and also dozens of pulldown menus (with user friendly labels) to control an LED on the side that nobody will ever use.  Then when it comes to setting the basic operational parameters needed to make the device work, the user has to consult an engineering guide specification sheet and find the correct hexadecimal parameter number.

The menu driven selection was totally up to the programmer to select decent usable parameters in the ISY that most users will use. I may never turn these receptacles on or off once set but those menus will still clutter up the ISY admin console with useless (to me) menus, status pages, and hundreds of settings.

Here are the webpages involved but still avoid the user friendly parameter setting to actually make the pages function. Do we really need a few dozen parameters to control the LED on the side of the receptacle while the basic threshold setting to enable/disable the metering is hidden in an engineering pamphlet, stated in Hexadecimal? I mean I grew up on tech bulletins, but a good majority of users will never make the thing run as the purchased it.

 

I guess what I am alluding to is if we had a database of these parameters, and if UDI were to build this idea into ISY. A customized pull down menu could be created. This way you would simply look up the parameters and then create the relevant pull downs. This puts no work or major changes on to UDI and still allows the user to create the UI the way they want.

3 hours ago, ase said:

 No one suggested UDI maintain the database. A database is very simple each person simply adds the parameters as they find them. This requires zero effort for UDI.

This concept is called crowd souce. It is how many companies support complex products. 

I am personally tempted just to host the database on my servers. 

Further no one has suggested that ISY or Polisy are for non tech people. There are however different levels technical understanding. I don't know your level however, I have written software, designed hardware, administrated networks for f500 companies as well as run my own IT firm. I am willing to bet that I see things very differently than the home grown hobbyist.

I would in fact advocate that professionals install home automation due to the technical and electrical aspects. However, the fact remains that will often not be the case. 

That being the case I believe that professional methods should be taught to those who are looking for guidance. After all the methods are built around safety and future troubleshooting.

Part of providing that support as a community is to build out information for common use by users at all technical levels. 

Nobody expects UDI to step up support, they expect the community to step up, after all they are the ones that derive benefits from it. A community is also an optional thing. The community isn't even just this one, it is people in the home automation community in general. 

A database of z-wave parameters would help all of the different home automation users.

The only real question for me is what format should be used.

Whoever you were implying should have a database is irrelevant. I did assume you meant UDI since you did not volunteer in your initial response and you said UDI should harness the community. If you werent referring to them you could have easily stated it was something you were looking to work with UDI on or take on for yourself.

With that said it doesnt matter who maintains a database, its still an extremely daunting task that requires a tremendous amount of manpower (man hours) to setup and maintain. The only thing worse than no database is a poorly maintained database with incorrect/out of date information. Take a moment to peruse the fibaro's manuals for their motion sensor alone (1st and 2nd gen). Then extrapolate that across thousands of different devices and firmwares (different firmwares support different things). So yes, while the community can add information to it, who will ensure it is the correct and up to date information (without losing or confusing with older devices). 

Lets say a database of every zwave device made is maintained and keep up to date with zero errors. How does that make it easier to find things than a person simply downloading the owners manual from the manufacturers website to their computer?

In regards to my non techie comment, read for context. It was a statement made towards another one implying that most of the general public wouldnt want to invest in the time needed to learn and setup an ISY/Polisy. The fact is, most people who use the ISY/Polisy will have some technical ability. Most of the non technical general public will automatically gravitate to easier systems such as smartthings, google, amazon, etc.

Nothing about this post has anything to do with teaching someone professional methods. Since you decided to mention that, we could talk about some of the things professionals do to make their installs much better.

One of the main things professionals will do that most do not is take the time to learn about their craft and the devices they plan to install. One of the simplest methods to do this is to read the manuals (which if this post is any indicator doesnt happen). Many people will create overly complex solutions to the most basic of problems and for what?!

Another is they focus on installing a limited number of devices. This allows them to focus on a few select devices and know them in depth. Trying to install a multitude of like devices is counter to that as the likelihood of being highly knowledgeable about the product goes down the more they use. 

Next, they just dont use the product. They'll test it. Learn its strengths and weaknesses so that they use it in the best manner possible for success vs. trying to fit a round object into a square hole. This includes but not limited to taking the time to learn all that you can about the chosen technology. If people took the time to do so, they would understand,the difference in how zwave handles different device properties via different mechanisms. If people do so, some debates such as this would be moot as they would understand the ROI on trying to build and maintain a database along with the additional coding needing to try to find the matching parameters.

No one is proposing a database of every parameter for every device ever made. You seem to have an Issue with reading into things whatever you want. There is a difference in parameters that are of use within the software and many of the device setting based parameters. Those "thousands of parameters" you refer to are often for hard coded items that no users are going to change, nor are they intended to be modified by a user. Many of them cannot be modified via software anyway. There would be no reason to deal with those. Say a thermostat has a parameter to modify temp tolerance, this is set and validated, users are never going to need that in a nice drop down interface.

Next your not going to bother tracking parameters for devices that are not currently produced. 

You also wouldn't track parameters of "low quality" manufacturers. Many of these devices don't have quality documentation.

Next most manufacturers assign the parameters across their entire product line. Take zooz for instance every single one of their dimmers use the same parameters to assign dim speed. So once that pattern is established, unless the manufacturers makes a change, the parameters can be applied across their product lines.

As for why I referred to UDI in a proactive manner is because as stated above UDI would need to make a few small changes to ISY to allow for either an external database to be imported by users or allow for custom parameters to be added within a device.

Either way I have begun contacting manufacturers to get full copies of how they assign parameters. I guarantee you that each manufacturer has a methodology.

Now if you have suggestions on how I should format the resulting data I would love to hear it. It doesn't doesn't matter if UDI uses the data or not. There isn't a comprehensive listing of parameters for the commonly used Z-wave devices and most of them have documentation that includes this information but not presented in an understandable format for most.

I have helped author some of the world's most used database driven CMSs, I am well aware of how to deal with large data sets.

All the best.

Here we go again with doom and gloom. It's been 17 years now and we're still here. It's just so exhausting.

With kind regards,

Michel

@ase,

If you can define a database that complies with node server schema, we can probably use it because I'm 5x, Z-Wave devices are node server based.

With kind regards,

Michel

2 minutes ago, Michel Kohanim said:

Here we go again with doom and gloom. It's been 17 years now and we're still here. It's just so exhausting.

With kind regards,

Michel

You're not allowed to go anywhere. Lol. You're too important. 

Seriously though

Thank you for all you've done over the last 17 years.

https://devices.zwave-js.io/

 

And a page pointing to other sources of data:

https://zwave-js.github.io/node-zwave-js/#/config-files/importing-from-others

 

The task, then, becomes figuring out how an end user might be able to use a script or tool to update their UI periodically as this information is updated (I'm not convinced the world needs Yet Another Database for the same info, when an aggregation tool might do the job).  And of course there's the licensing aspect, but as long as the end user runs the tool and the DB is not distributed with the product, there's probably no insurmountable issue no matter how the data source is licensed.

Edited January 31, 20223 yr by mwester
Add additional URL and some commentary.