Andy P

Pul all of the away programs in a folder. I use the name Random because the lights have a random pattern. Create a State (boolean) variable $State_Random. Set the folder condition to IF $State_Random is 1 Put a scene controller by the door that you exit - use that to turn the random mode on and off. Very easy as you leave the house! Assign one of the buttons of the scene controller to a scene called Switch Random. Create these programs SC Random On Switch If 'SC / Mudroom Scene.B' is switched On Then Run Program 'Turn Random On' (Then Path) Resource 'Notify Random On' SC Random Off Switch If 'SC / Mudroom Scene.B' is switched Off Then Run Program 'Turn Random Off' (Then Path) Resource 'Notify Random Off' Turn Random On If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then $State_Random = 1 $State_Random Init To 1 Set 'Switch Random' On Else - No Actions - (To add one, press 'Action') And Turn Random Off If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then $State_Random = 0 $State_Random Init To 0 Set 'Switch Random' Off

OK, Thanks, very helpful to confirm that the scene buttons only turn on and I didn't mess anything up. Based on this, I have changed my usage as follows. created a scene with the loft light switch added shop stairs button 2 as a scene controller to turn the scene ON. added shop stairs button 4 as a scene controller to turn the scene OFF. set the color of button 2 LED to green (parm 8=2) set the color of button 4 LED to red (parm 10=3) created a program that runs when the loft light status changes to turn the button leds on and off So now, I can turn on the loft light with button 2. Turn off the loft light with button 4 and when the program runs, it either turns on the green light on button 2 or the red light on button 4 and turns the other light off. Here is the program - had to add the waits to get it to work correctly Loft light status - [ID 0009][Parent 0007] If 'Shop Loft-Binary' Status is On Then Wait 1 second Set 'Shop Stairs-Binary' Set Configuration Parameter 3 = 3 Wait 1 second Set 'Shop Stairs-Binary' Set Configuration Parameter 5 = 2 Else Wait 1 second Set 'Shop Stairs-Binary' Set Configuration Parameter 5 = 3 Wait 1 second Set 'Shop Stairs-Binary' Set Configuration Parameter 3 = 2 Doing the same for the attic light so this effectively gives me a switch that can turn the stairs light on or off with the big button and turn the loft and attic lights on and off with each using a pair of small buttons and including indicators of being on or off on those buttons. Thanks for your help! Andy

I am in the process of moving my z-wave devices from Hubitat to the z dongle on EISY (5.6.0, 5226, 21100), and have a lot working but some strange behaviors. I followed the process of exclusion, factory reset then inclusion to get the best results. The ZEN32 has one button (called the relay and also called button 5) and 4 smaller buttons are called 1 through 4. Adding the device creates 11 nodes: 1 node for the relay called _1 Binary Switch 5 nodes for the small buttons plus the relay called 201N001 through 201N005 Central Scene Control Button 5 nodes for the small buttons plus the relay called 252N002, 4, 6, 8 and 10 Basic Association So, the normal operation of the big button does cause the Binary Switch node to change from On to Off and back again, and I can also control it through programs - all good. Pressing small button 3 generates a log entry. Sun 06/25/2023 08:27:09 AM : [D2D EVENT ] Event [ZY017_201N003] [DON] [0] uom=115 prec=0 Sun 06/25/2023 08:27:09 AM : [ZY017_201N003 ] DON 0 (uom=115 prec=0) Sun 06/25/2023 08:27:09 AM : [ZWAVE-CTL-EVENT ] Basic Set from 17.0 unmapped (ignored) So, it says unmapped ignored (although it will trigger program execution). First questions - when I turn on zwave -> detect button presses I can get the dialog box to pop up, but there is no node than allows me to 'right click on an association only node' and map the button - so does that actually work? Second question - when I press button 3 again, it again generates a DON event. No matter which button I press, or how many times, they only generate DON events, never DOF. I reviewed the advanced settings for the device and there is no setting that would appear to cause this behavior. SO, how do I get this device to generate both DON and DOF events? One side effect of this behavior is that when I assign a button to a SCENE as a controller and add another switch to that scene, I can turn that Scene ON but cannot turn the scene back off using the ZEN32 buttons. I also tried using the Basic Association nodes, but they don't seem to generate any events at all in the log (at level 3). My work around right now was to create a program that basically uses the DON events to toggle the other switch - here using button 1 which toggles the loft lights when the stairs button is pressed repeatedly. I am using 'switched on' instead of 'status on' because if you use 'status on' the program just goes into a loop turning itself on and off. Zen32 - [ID 0018][Parent 0007] If 'Shop Stairs-S1' is switched On And 'Shop Loft-Binary' Status is Off Then Set 'Shop Loft-Binary' On Else Set 'Shop Loft-Binary' Off I can live with the work around, but it means that the LED indicator is out of sync sometimes with the on/off status so I would really like to get the buttons to generate off events and get the scenes working. Any ideas? I am reaching out to ZOOZ as well for firmware updates. Andy

I just received my dongle as well - no instructions in the box, but found the answer in this post - nice to have an active user community!

I had a similar issue - the backlight setting of zero doesn't equate to off. But then I found under Options there is a checkbox setting called No LED. Checking that turned it off entirely. Don't know how to access that programmatically, but I turned off the bedroom switch LEDs using that option.

I'm hoping Michel has access to an early version of the 4-button keypad so we can use it with the EISY as soon as it ships!

I had a similar problem a couple years ago and had no idea that the UPS I plugged in to a circuit near the PLM was causing it, but after going around unplugging almost everything in the house, it turned out to be the cause. It was great that plugging the UPS into a noise filter fixed the problem immediately. I just recently started having issues in my barn with the mini-remote not turning on some switches and then I realized I had a UPS there with no filter. After adding the filter, the remote works every time. Definitely recommend adding the filter for reliability.

I have to agree with that - I always use 'add device and remove existing links' to avoid unexpected consequences

I walked away from Indigo three years ago and started over with a 994. Now running on the EISY. The UD hardware and software is rock solid. I miss two things from Indigo, though. The admin console equivalent was a bit easier to use and navigate and the ability to create web portals with device control and status was amazing. There were some issues with compatibility with new MacOS releases at the time which was annoying. During the transition, I bought a new PLM and set up everything in parallel with Indigo before shutting it down. Also tried using the ISY bridge software to sync status to indigo for a while after removing the PLM from indigo, but decided that was not responsive or reliable enough to continue. I ended up using Hubitat for the zwave stuff, but once the zwave/matter usb device is in stock again, I plan to get one of those for the EISY. Good luck with the transition! Andy

Just tried this node server. Installed ok and created two nodes - one for the connection and one for the spa. Yes, I set the host parameter to the IP address. But all the values are zero. In the log, there is a message :AttributeError: module 'pybalboa' has no attribute 'BalboaSpaWifi' when I try to set any value I looked at the package on github and there is no pybalboa.py in the package. So then I searched github for pybalboa and found that in a separate project. It looks like that module has had extensive changes including deleting pybalboa.py and replacing it with client.py So the question is - is there any active development on this node server and does the nodeserver need to be updated to use the new version of pybalboa or to have an old version of pybalboa included in the 3.0.0 version? Or am I doing something wrong? Thanks, Andy

It works!!! Thanks, Bob - perfect fix. Now I am getting all the button events in the polyglot console and the admin console and the programs are triggering properly. I went ahead and bought the production version - but, oops, on the wrong EISY. So bought another for my House EISY. Now I just have to buy a Lutron hub for my barn so I can use the Pico remotes over there. Thanks again, Andy

Thanks! i will give it a try as soon as i have a chance and let you know. Andy

Just to add that. when I use the PJ2-3BRL remote, I see these entries as expected 2023-05-25 12:43:40,489 Thread-2 udi_interface DEBUG picos:btn_off_callback: Button off was Press 2023-05-25 12:43:40,489 Thread-2 udi_interface.interface DEBUG interface:send: PUBLISHING {'command': [{'address': 'device11_1', 'cmd': 'DOF'}]} 2023-05-25 12:43:40,507 MQTT udi_interface.interface DEBUG interface:_message: QUEUING incoming message command 2023-05-25 12:43:40,507 Command udi_interface.interface DEBUG interface:_parseInput: DEQUEING command 2023-05-25 12:43:40,801 Thread-2 udi_interface DEBUG picos:btn_off_callback: Button off was Release

Yes to everything about the node created for each button. And exactly how I set up the programs. The problem is, no event is generated at all for any of the buttons and so no programs run. I turned on debug logging in the polyglot console and there is no log entry when I press a button and no action in the EISY admin console either for that remote. If I set that exact remote through the lutron app to control a light, I do get events for the light in both the log and in the admin console as I mentioned. This is the PICO remote model that has no Favorite button in the middle, but other than that seems to be the same. Andy

Hi Bob, first of all, I am trying out the Caseta node server. No problem loading it up and getting it to recognize my hub, three switches, shades. But although the node server creates a node for the 4 button PJ2-4b, there are no events in the log when any button is pressed. Any idea what is happening? I can set that remote in the Lutron app to control a light and will get the events in the log for the light. But I wanted to repurpose the remote to control insteon devices so I need to get the events directly without controlling a caseta switch. Node Name 12AddressNodeDefPrimary NodeHintEnabledIs PrimaryDelete Study_Pico - Adevice19_1pico4bdevice19_10x00000000truetrue✖ DriverUOMValue ST251 Thanks, Andy

Based on my migration experience which is in another post, I would recommend that before shutting down the old ISY, go into Tools - Diagnostics and look at the existing PLM links especially the count and make a note of it. When you get to step 5 on the EISY, do Tools - Diagnostics - PLM Info/status and make sure it says connected before performing step 6. You can use the Tools - Diagnostics - Event viewer while it is writing the link table to the PLM to see progress. When Step 6 is done, again do Tools - Dianostics and verify that the link count on the new PLM is the same as you had on the old one. Andy

One other thing I noticed when I added the DIAL device (at 5.5.9 haven't had a chance to test at 5.6.0) is that the admin console will show a default ON LEVEL of OFF (the lowest possible value) and a default RAMP RATE of 9 minutes (the highest possible value). So, when I first tried to use the admin console to turn the device on and off, I thought it wasn't working until I changed those values to ON LEVEL 10% and RAMP RATE 0.5 seconds. Just a heads up to anyone scratching their head. I assume this means that the EISY has no way of reading those values from the device, but maybe someone knows more about that?

Thanks for the hint on the update - that one snuck out when I wasn't looking! So, the good news is that with 5.6.0 the EISY is reflecting the update in dim level caused by rotating the dial. That is great. The other problem remains. If you change the default dim level using the set switch under the dial and then turn it off and back on, the EISY thinks it is at the default dim level set by the admin console. You can run QUERY and it will read the correct current DIM level. One minor quirk. Let's say you used the set button on the device to set the default level to 100%. Then you go to the admin console which shows On Level 10%. If you just press the ON LEVEL button, it won't write the change to the device because it thinks the ON LEVEL is already set to 10%. I verified that in the debug console - zero bytes written. But if you change it to 11% and press ON LEVEL, it does set the default on level to 11%. Really glad the local dimming changes are now working. I can live with the others.

I received my first I3 devices. Had no problem linking the I3 Dial from the EISY 5.5.9 admin console using the address printed on the front of the switch. Didn't touch the switch at all during linking. It is unfortunate that the dial does not report local dimming changes back to the EISY, but on/off does get reported, obviously. However, if you change the default ON level at the dial using the SET button, when you turn the switch off and back on locally, it comes on to the new level you set, but the EISY still thinks it turned on to the default level set by the Admin Console. If you then do a QUERY, it will read the actual brightness level of the switch.

Makes complete sense and I think your last statement is the most important - it works the way someone would expect it to. I also set up a number of programs called 'minimum dim level from off' in bedrooms and bathrooms. The problem I was trying to solve was that the default dim level is great most of the time, but if you are in the middle of the night, you just want to turn the light on to the lowest level that won't flicker. So if the light is off and you press off, the minimum dim program runs and you have a nice dim light. Works great for me, but doesn't meet the WAF because she likes to hit the off button on lights that are already off just to make sure they are off - bad surprise! I might change it to fast off when off. Andy

For example. I have a scene controller (keypad 2334-232) button C which turns on the cooking scene - which includes undercounter lights, recessed lights and pendants. I normally use the scene controller (keypad) to turn them all on and off. HOWEVER, my wife likes to turn off one or more of the individual switches. So then all the lights are off but the C button is still lit. My question is - what are best practices to keep scenes and individual switches in sync given there are lots of combinations of the switches that will be in use during the evening, not just ones that are exactly the same as a scene. The one thing that I have recently done is to add a program, which I call 'Cooking scene backstop', that says if (sw1 and sw2 and s3) are off, then turn off the scene, so at least I don't have the stray scene button light on any more that I have to turn off and then back on to get the scene to come on. Thoughts? Andy

Just to follow up - everything is working and the ticket is closed. There is no factual explanation for what happened but I have offered this theory based on some post analysis of the files I saved After the first migration attempt, the PLM had 102 total links, with exactly one link for each of 102 devices - i had no idea if this was right or not - some of you probably would have known this is wrong. After the second migration, the PLM had 469 links, with 2 to 10 links for each device (lots of scene controllers) My theory is that there was a communication error with the PLM during the first migration and the restore process put the first link into the link table and then attempted to write it to the PLM but failed and then went on to the next device. Which means the table had an entry but the PLM did not. Then, when I tried to do a restore PLM to fix errors I was seeing, and after rebooting everything, there was no more communication error and it wrote each of those single links to the PLM giving enough functionality that I thought the migration had worked, but of course it did not. The compare links process didn't indicate any error because the links in the PLM matched the table that was built during restore which was missing many lines. If there is any possibility that something remotely similar to this happened, I recommend the following process if you are changing PLMs: 1. On the original ISY, before migration, examine the PLM links and make a note of how many there are and then run a backup ISY. 2. On the new EISY, after booting it up and before migrating, go to the Tools - Diagnostics - PLM Info/Status option and make sure it shows your PLM connected 2. Do File - Restore ISY with the event viewer visible and logging level 3 enabled and watch the results 3. After the restore, again examine the PLM links and see if it matches pre-migration. Thanks again to all, Andy

OK, started the whole migration over again using the same backup as before and this time it worked. 1. On the EISY admin console, did File - Restore ISY 2. After the reboot of the EISY, checked the links tables and they still show the old PLM (of course) 3. Did a File - Restore Modem (PLM) That is pretty much the same thing I did the first time. But this time, it worked and now there are many more links in the PLM and the EISY is being notified on all device changes. I guess the technical explanation is that all the controller links were in place after the migration but none of the responder links - or the other way around - not an expert on that, obviously! Don't have a clue why the first migration failed, but happy that it worked the second time. I guess my only advice out of this is don't spend hours trying to troubleshoot a migration which is partially working and just start over again. Thanks to everyone for your support and suggestions! Andy

ok, based on ideas above, I deleted one of the devices and added it back and that device does trigger the EISY correctly. It seems that all of the A2 links were written to the devices during the migration but none of the E2 links were to any device. And apparently the EISY doesn't expect them to be there so doing restore to the device or the plm doesn't put them back. I guess the next step is to trying doing a restore from backup again and see what happens.

Yes, i have done restore PLM several times and I have done restore devices several times. I can hear the PLM beep and then each device beep as it goes through the process. Here is a snip of the PLM (1e.4d.5b 2413U) table and then the first device in that table 50.88.d4 which is a dimmer in the main hallway. Waiting for response to the ticket, thanks for your ideas.