ELK not showing ISY Insteon status, but ELK can control ISY

[HomePlicity]

I have been fighting this problem for a year. I ended up restoring isy and then adding links and scenes using the isy99 only. If your using the ISY99 with and ELK, never ever manually link any switched by pressing buttons. Only use the ISY99 to add devices, linking and scenes. If you manually link a button, the ISY does not know about it and will not pass the info onto the ELK. I had to change how I thought about Insteon, and once I starting using the isy99 as the master controller and never manually linked anything, my problems went away. Good Luck

[stephan]

now this is an old thread started 5 years ago and people like me are still having issues with it. I started with ISY 3 months ago and I love it. I did all my programming of the insteon devices through the ISY as suggested by the previous post.

Unfortunately I have the exact same problem of scenes not working. The device itself works just fine.

 

Here is the exported xml file:

 

1D A8 65 1

Office Printer Device

2.9.66.0

A05

5845

Printer Scene

A01

 

 

As you can see very simple. Only one device is part of that scene. But I have to use a scene in-between because my KPL Button A cannot be controlled any other way. I also have many other scenes for which I would like to use the scene to control it.

 

I can control my printers through the scene through the Elk just fine, but I cannot see any updates when I use my KPL to turn them on/off.

The device lighting indicator works just fine on the Elk, so I assume that all the communication between the M1 and ISY works just fine. I have all options in the Globals sections of the Elk checked.

 

How can I fix this ?

 

Stephan

 

P.S. I have the Elk Module for ISY and I can arm/disarm and do everything else successfully

[Michel Kohanim]

Hello stephan,

 

What do you mean by "a scene in-between"?

 

You can have one scene with your KPL and printer both in the same scene. Are you trying to change the status of the KPL button without controlling the printer?

 

With kind regards,

Michel

[stephan]

My apologies, that was expressed badly. What I meant is that I have to use a scene for my Button A on the KPL so that I can use it to turn the printer on and off. The scene has one controller (Button A) and one responder (printer).

 

Hope that clarifies it.

[stephan]

On top of that I wanted to share another inconsistency with the previous post in earlier years. As you can see in my post above the scene (group) in the exported xml doesn't have the link element which tells elk which other devices are in the scene. This in particular makes me wonder how in the hell the Elk should know this. Unless the system was changed and the ISY is now actively telling the Elk if a scene is in the ON/OFF status ?

 

Thanks

[Michel Kohanim]

Hello stephan,

 

Thank you for the clarification.

 

Questions:

1. Do you see any status updates on your ELK at all?

2. If you click on the printer scene in Admin Console, and then turn on/off your KPL, does Admin Console's status reflect the reality?

 

With kind regards,

Michel

[stephan]

1. Yes, I see updates to all my individual insteon devices, but not to any scene in ELK

2. Yes, My Admin Console always reflects the correct state.

 

I also happen to have the MobiLinc App, and this always reflects the correct state as it goes to the ISY directly, it is just the Elk connection that doesn't work for scenes.

[Michel Kohanim]

stephan,

 

Scenes, in and of themselves, do NOT have any status in ISY. Is that what you are referring to?

 

With kind regards,

Michel

[stephan]

no.

I don't see whether scenes are turned on or off in the Elk. I can export them using the Elk Config screen in the ISY and I can import them in the Elk RP software, but if the status changes of scenes (such as all devices in a scene are turned on) I don't see that the scene is turned on in the Elk.

 

Are you saying that scenes are not supported ? I don't see this mentioned anywhere in the wiki for the Elk module.

 

-Stephan

[stephan]

Let me add to that. I have the exact behavior as "telljcl" reported on "Wed Feb 09, 2011 11:00 am". Exact same behavior as he had. This is the problem. Not sure if that helps or why my explanation is confusing.

Also, Michael you said on "Fri Feb 04, 2011 1:34 am" - "I do not think that is true: ELK should reflect the status of devices as they change in ISY (as long as they are imported in ELK)."

And this is what I don't see happening for scenes

[Michel Kohanim]

Hello stephan,

 

Scenes do NOT have status in ISY. That's why you do not see a scene status in Admin Console and that's why you do not see a scene status in ELK! Scenes do NOT have status.

 

And, this is a design decision for which we have had 100s of posts/feedback but, at the end of the day, we decided that ISY scenes should NOT have status.

 

With kind regards,

Michel

[stephan]

Thanks for the reply and clarification. For my understanding then can you clarify this behavior ?

 

I have a scene called "Printer Scene", I also have a device "Printer" which is an appliance module.

When I look through MobiLinc, I see On for "Printer Scene" as well as "Printer". Is this something that MobiLinc does by looking at all devices ?

When I look at both lighting devices exported from ISY and imported into Elk, then I see off for "Printer Scene" and on for "Printer".

I guess I just don't get why there is a difference between the two.

 

Lastly, I have not seen this restriction for the Elk anywhere before. It would be nice to have this documented on the wiki.

 

Thanks as always

Stephan

[Michel Kohanim]

Hi stephan,

 

 

I have a scene called "Printer Scene", I also have a device "Printer" which is an appliance module.

When I look through MobiLinc, I see On for "Printer Scene" as well as "Printer". Is this something that MobiLinc does by looking at all devices ?

I am so very sorry but I really do not know what MobiLinc does. Suffice it to say that it's not coming from ISY.

 

When I look at both lighting devices exported from ISY and imported into Elk, then I see off for "Printer Scene" and on for "Printer".

Off is the natural state for all devices in ELK unless ISY publishes updated status otherwise.

 

I guess I just don't get why there is a difference between the two.

Do you mean MobiLinc and ELK? If so, unfortunately I really cannot answer this question. Scenes cannot have statuses simply because you may have multiple controllers therein each one of which could have a different impact on member devices. If clients decide to show status of a scene based on member device status, then it's 100% up to them.

 

Lastly, I have not seen this restriction for the Elk anywhere before. It would be nice to have this documented on the wiki.

This is not a restriction on ELK. This is how ISY processes scenes.

 

With kind regards,

[stephan]

Thanks Michael. Trying to summarize here so that others who read this thread don't get confused.

 

In essence what was written in this thread in the earlier years is incorrect. The facts are that scenes do not carry a status and therefore the status doesn't get reflected in the Elk environment. Devices have a status and therefore it gets reflected.

One can still export scenes as well as devices to Elk, but the purpose for scenes is only for triggering them, not for reading any status off of them.

 

Is that about it or is there more ?

 

Thanks for all the weekend work in answering my questions !

 

Stephan

[Michel Kohanim]

Stephan,

 

Couldn't have said it better! Thanks so very much for the summary.

 

With kind regards,

Michel

[MWareman]

The facts are that scenes do not carry a status and therefore the status doesn't get reflected in the Elk environment. Devices have a status and therefore it gets reflected.

One can still export scenes as well as devices to Elk, but the purpose for scenes is only for triggering them, not for reading any status off of them.

Sorry to revive this old thread. I have one thing to add - possibly a request or two - and a couple of questions. I had exactly this 'issue' - and my search led me here.

 

First, I *fully* understand that 'Scenes do not have a status'. I 'get' why this is...

 

However, I (like many I think) have many scenes in ISY that control a single load device. In these cases - it's appropriate to have the scene report that devices status as the scene status. It seems odd that we can not (optionally) designate a device as the 'load' or 'primary' device for a scene - and have ISY report a scene status if this is provided. Could you consider implementing in ISY an option to optionally specify a 'load' device within the scene (a simple radio button). This 'load' device would provide status for the scene when queried. If no load device is specified - the scene would behave exactly as it does today with no status. This would seem to provide a possible way of satisfying both side of the argument without breaking existing program logic in any way. I know this has been hashed many times - and I fully understand it if I receive a summary beating for bringing it up (again) - so I'll leave this suggestion at this point and back away quietly.

 

However, aside from the scene status issue the ISY is fully aware of when I send a 'Scene On' and 'Scene Off' command, either from the GUI or via any scene controller device. Why couldn't this command be forwarded to Elk - in the same way as it is with devices - allowing the Elk to update the node status in response - resulting in depiction of the scene status in ISY? That seems like an odd omission given that ISY allows the exporting of scenes to Elk. Of course - this requires the PLM to be registered internally as a 'responder' to all scenes - but I think that's already the case, isn't it?

 

Another idea - is it not possible for Elk to implement on the Elk side the ability to optionally select a 'status' device for each lighting node? So - 'Scene' A3 (a 'shown' SCENE from the ISY for control purposes) could have a status device of, say, D8 (a 'not shown' DEVICE from the ISY for status purposes). The status device would be the load device of the scene on the ISY (so status is reflected accurately and - essentially - copied to the status of the scene device). This would have the negative effect of halving the possible number of devices - but that's a limitation I would accept for this functionality - and would be an end user choice.

 

The only published alternative is, as mentioned on the wiki, have the Elk directly control the load device (instead of a scene) and write an ISY program to trigger the associated scene (that does not include the load device) from the changing load device status. This seems to requires maintaining two copies of each scene I think (One that lists the 'load' device as a controller - with all secondary devices in it as controllers - and a second that lists all devices except the load device - with all others only responders). Less than ideal in the long run - and does not seem to support sending the status of dimmed lights between switches (due to lack of ability to copy current device 'brightness' to a variable - or setting a device brightness to a variable value - or copying the brightness of a device to a different device).

 

Has anyone come up with a better way of:

 

1) Exporting only SCENES from ISY to Elk (easy, of course)

and

2) Having that node status accurately reflect the status of the load device of the scene? (If such a status device is available)

 

I tried writing an ISY program to update the Elk light status when the load changes state. I cannot seem to set a light device from within an ISY program using the Elk module - this does not seem supported. (Please Please add this to the Elk module so we can eliminate having to manually figure out the string and crc!)

 

I see that the M1XEP has a control socket that can be used with the networking module. I found this post http://forum.universal-devices.com/viewtopic.php?p=32771#p32771 - but the links to the documentation and CRC calculator are broken. Found a newer tool within their portal - the 'Software Developers Tool' (http://www.elkproducts.com/_literature_ ... per's_Tool) that can generate the CRC.

 

So - device A6 'On' is 09pnA0600B2 and A6 'Off' is 09pfA0600BA. Sending this to TCP/2101 'C-Escaped' works beautifully to control the lighting device (and, therefore, Elk's reported status). However - having an ISY program run the network resources in response to device status seems to only half work. This is the program I am using currently:

 

'Main / Kitchen / Kitchen Keypad - Kitchen Over' is the load - button 1 on an 8 button KPL. 
'SC - Kitchen Overhead' is a scene. Button 1 of the KPL is both a controller and responder of the scene.
I have two other switches (actually - buttons on 8 button KPLs) that are non-load but both 'controller' and 'responder' of the 'SC - Kitchen Overhead' scene.
The 'SC - Kitchen Overhead' scene is exported to the Elk as device A6.
'Report Elk Status - Kitchen Overhead OFF' sends '09pfA0600BA\r\n' to the Elk on TCP/2101
'Report Elk Status - Kitchen Overhead ON' sends '09pnA0600B2\r\n' to the Elk on TCP/2101

If
       Status  'Main / Kitchen / Kitchen Keypad - Kitchen Over' is Off

Then
       Resource 'Report Elk Status - Kitchen Overhead OFF'

Else
       Resource 'Report Elk Status - Kitchen Overhead ON'

 

(Another aside - why is there no program trigger for 'Control' of a scene?)

 

Turning the 'Main / Kitchen / Kitchen Keypad - Kitchen Over' device 'Off' at any scene controller results in the Elk A6 device showing 'Off'. Perfect.

However, turning the scene 'On' via any scene controller does not update the Elk for some reason. Manually testing the network resources works perfectly.

Is there a better way to do this - or am I over thinking it?

 

Fundamentally - I see this more as a documentation issue (still!). May I suggest under the 'FAQ' section on http://wiki.universal-devices.com/index.php?title=ISY-99i/ISY-26_INSTEON:ELK_Configuration you list something like:

 

'While Scenes can be exported from ISY to Elk - due to limitations on Insteon scenes no status information is sent and the ELK will not reflect the status of any devices within the scene'

 

Even though I'm fully aware of the scene/status limitation, I did not make the connection to it's implication when integrating with the Elk. It really does mean I'm going to have to forklift my configuration to make this work - or just forget about integration of my lighting into Elk.

 

What to do... I don't know. I was hopeful the network resources and program would work around the issue.

 

Thanks for the soapbox!

 

Michael.

[Michel Kohanim]

Hi Michael,

 

However, I (like many I think) have many scenes in ISY that control a single load device. In these cases - it's appropriate to have the scene report that devices status as the scene status. It seems odd that we can not (optionally) designate a device as the 'load' or 'primary' device for a scene - and have ISY report a scene status if this is provided. Could you consider implementing in ISY an option to optionally specify a 'load' device within the scene (a simple radio button). This 'load' device would provide status for the scene when queried. If no load device is specified - the scene would behave exactly as it does today with no status. This would seem to provide a possible way of satisfying both side of the argument without breaking existing program logic in any way. I know this has been hashed many times - and I fully understand it if I receive a summary beating for bringing it up (again) - so I'll leave this suggestion at this point and back away quietly.

It is definitely possible ... the question is how important is this feature compared to everything else we have to do.

 

However, aside from the scene status issue the ISY is fully aware of when I send a 'Scene On' and 'Scene Off' command, either from the GUI or via any scene controller device.

Not an entirely true statement. Yes if from a client on ISY. As far as a controller, within the scene, well, ELK does indeed get this event from the switch. If you say this should also become a scene command, well, then, we are back to square one.

 

Why couldn't this command be forwarded to Elk - in the same way as it is with devices - allowing the Elk to update the node status in response - resulting in depiction of the scene status in ISY? That seems like an odd omission given that ISY allows the exporting of scenes to Elk. Of course - this requires the PLM to be registered internally as a 'responder' to all scenes - but I think that's already the case, isn't it?

See above.

 

Another idea - is it not possible for Elk to implement on the Elk side the ability to optionally select a 'status' device for each lighting node? So - 'Scene' A3 (a 'shown' SCENE from the ISY for control purposes) could have a status device of, say, D8 (a 'not shown' DEVICE from the ISY for status purposes). The status device would be the load device of the scene on the ISY (so status is reflected accurately and - essentially - copied to the status of the scene device). This would have the negative effect of halving the possible number of devices - but that's a limitation I would accept for this functionality - and would be an end user choice.

I do not know!

 

The only published alternative is, as mentioned on the wiki, have the Elk directly control the load device (instead of a scene) and write an ISY program to trigger the associated scene (that does not include the load device) from the changing load device status. This seems to requires maintaining two copies of each scene I think (One that lists the 'load' device as a controller - with all secondary devices in it as controllers - and a second that lists all devices except the load device - with all others only responders). Less than ideal in the long run - and does not seem to support sending the status of dimmed lights between switches (due to lack of ability to copy current device 'brightness' to a variable - or setting a device brightness to a variable value - or copying the brightness of a device to a different device).

I think you are making things too complicated. If your premise is that most scenes have one controllers, then just use the status of that controller for everything you are suggesting. NOTHING has to change in ISY/ELK or any combination thereof.

 

I tried writing an ISY program to update the Elk light status when the load changes state. I cannot seem to set a light device from within an ISY program using the Elk module - this does not seem supported. (Please Please add this to the Elk module so we can eliminate having to manually figure out the string and crc!)

I really have no idea what you are referring to. The status of lights in ELK are reflections of their status in ISY. We cannot in any shape or form circumvent this design decision or, otherwise, we'll have out of synch status between ELK/ISY.

 

I see that the M1XEP has a control socket that can be used with the networking module. I found this post http://forum.universal-devices.com/viewtopic.php?p=32771#p32771 - but the links to the documentation and CRC calculator are broken. Found a newer tool within their portal - the 'Software Developers Tool' (http://www.elkproducts.com/_literature_ ... per's_Tool) that can generate the CRC.

 

So - device A6 'On' is 09pnA0600B2 and A6 'Off' is 09pfA0600BA. Sending this to TCP/2101 'C-Escaped' works beautifully to control the lighting device (and, therefore, Elk's reported status). However - having an ISY program run the network resources in response to device status seems to only half work.

See above. My recommendation is to disable the ELK Module since you are circumventing what ISY does. It's like controlling an INSTEON light in ISY using SmartLinc. It just does NOT work.

 

With kind regards,

Michel

[MWareman]

My recommendation is to disable the ELK Module since you are circumventing what ISY does. It's like controlling an INSTEON light in ISY using SmartLinc. It just does NOT work.

Michel,

 

With all due respect - this is NOT what I am trying to do.

 

http://wiki.universal-devices.com/index.php?title=ISY-99i_Series_INSTEON:ELK_Security_Module, section 5 describes:

Export Lighting Devices to Elk

From the ISY Admin Console
Click on the Configuration tab
Click on the Elk sub tab
Click on the Export sub tab
Add devices to be to exported to Elk by selecting them from the Available column and pressing the [Add to Export List] button
An ID is automatically assigned to each entry, but you may customize it by double clicking the value and entering any valid, unused X10 id. (e.g. B12)
Click the [save] button
Click the [Export] button
This will save an export file on your computer, please note the location.
From Elk RP2
Go to Automation, right+click on Lighting, and select Import Lighting Data ...
Enter the name of the export file.
Select Universal Devices ISY export for an Insteon network
Click the [import] button
Click [send to Control] button (you may need to connect first)
Click the Save icon below the main menu bar

 

I am simply doing this. Are you saying this is NOT a supported use of the Elk module? If so - it is grossly misrepresented on your sales materials. I suspect this is actually intended to work - based on your documentation.

 

My primary use of the Elk module is to expose the security sensors and status of the area state on Elk to the ISY system - for lighting automation and presence. For this purpose - it works perfectly and I am very happy with it. I certainly have zero intention of disabling it - although my verdict on controlling the ISY from the Elk is still out. I do realize that this is the responsibility of Elk to improve this end of things - not UDI.

 

Problem I have is this: ALL my 'loads' are scene responders (in ISY) - and each 'scene' has one or more 'controllers' (many 6 or 8 button KPLs). The only entities exported from ISY for import to Elk are scenes. The scenes I have exported all contain ONLY a single 'load' device. Is this wrong? I do this because I often have one or more report 6 or 8 button KPLs as scene controllers - and I need the status of the light on these buttons to accurately reflect the status of the controlled device.

 

When I export from ISY and import to Elk one of these ISY scenes, and assign it to a function key on the keypad - I can reliably turn the scene on and off from the keypad. The 'status' (lighted state) of the key on the keypad mirrors the scene when controlled this way. However, when controlling the scene from any other method (MobiLinc or a switch) - the status of the device on the Elk keypad does not change. We know why - 'scenes' do not have status in ISY. That's fine - it's a limitation we are living with. All my discussion was centered on getting scene commands from scene controllers out to the Elk, so the button state can be updated in the same way that KPL button states change. I think you may have missed that - or I simply worded it badly.

 

My understanding of the ISY / ELK integration is that you can and should be able to control lighting in ISY from ELK keypads - rather like MobiLinc can control lighting in ISY. This is NOT an INSTEON vs INSTEON battle with ISY in one corner. The ELK does not have it's own Insteon connection - only a network connection to ISY. This is NOT like a SmartLinc competing with the ISY.

 

Personally, I think the ability to export 'scenes' from the ISY for import (as devices) to Elk should be disabled - and you should only be able to export 'devices'. That would then mean that full functionality is obtained for devices that are exported - and the resulting confusion would be lessened.

 

I tried writing an ISY program to update the Elk light status when the load changes state. I cannot seem to set a light device from within an ISY program using the Elk module - this does not seem supported. (Please Please add this to the Elk module so we can eliminate having to manually figure out the string and crc!)

I really have no idea what you are referring to. The status of lights in ELK are reflections of their status in ISY. We cannot in any shape or form circumvent this design decision or, otherwise, we'll have out of synch status between ELK/ISY.

 

When the 'device' on Elk is a 'SCENE' on ISY - they already have out of sync status. The the basis of the reported difficulty.

 

Allow me to further clarify. I have a SCENE on ISY that is exported to Elk. Elk has no concept of SCENES - only DEVICES. I am trying, thru the use of programs - send the status of the DEVICE (being the load device from the scene) on ISY with the DEVICE as represented in Elk.

 

Now - as very well represented - SCENES on ISY do not have status. I get that. However, if a scene has only ONE load device - then that device status becomes an accurate representation of the scene. Or am I missing something here?

 

If I only export the load device from ISY to Elk - the status works fine for the device. Even when controlled from the Elk and thru MobiLinc and other scene controllers (KPL buttons). The problem with this configuration is that when I control the device from Elk - my other scene controllers (buttons on KPLs) become out of sync with the status of the load device. This is what I'm trying to avoid or solve.

 

Perhaps a better (or at least more palatable) solution is the following.

 

The Elk module on ISY allows program triggers and control from 'Area' 'Zone' 'Keypad' 'Output' 'Thermostat' 'Audio' and 'Speak'. Why is Lighting not supported here?

If I could create a 'light' on Elk not actually connected to anything - and have the ISY change the state of that 'light' via program.

Then have a program trigger on the Elk 'light' changing state - and in turn trigger the scene.

 

At the end of the day - I'm just trying to get lighting integration to work between Elk and ISY. I also want all my KPL button light and Elk button lights to remain in sync - it a button light is on - the light is on (etc). Does not seem like too much to ask - but seems to the the holy grail.

 

Basically - all I want is the button on Elk to control the scene (it does this fine) AND for the button status to represent the status of the scene - in the same way a KPL button assigned as a scene controller accurately represents the status.

 

How is everyone else doing it? Or is nobody else doing lighting integration between ISY and Elk?

[madcodger]

Mwareman,

 

I've read your thread a couple of times trying to understand this. When you say "control lighting from Elk", do you mean from an Elk Rule, or by pressing a button on an Elk keypad?

 

Personally, I just ended up writing a bunch of ISY programs that tell my system the state of various scenes. ISY variables might help you there. This approach works out well for me, and might be worth considering.

 

The other thing I've found is that the Elk is, essentially, a fairly poor lighting controller, at least with Insteon. It was originally based on X10, and imports into the Elk still reside in X10 "slots", with no ability to control what devices end up in what slots. Because of that, I personally find that the Elk is great for holding certain rules that AFFECT lighting (If door A opens, Then...) but I find it better to have the Then statement simply change an output in Elk that the ISY can read.

 

To some degree, the Elk module does a better job of allowing ISY to know what Elk is doing than allowing Elk to understand ISY or Insteon. When possible, I think it's better to have lighting logic and control on the ISY side, with certain "state" changes (door opens, system armed, etc.,) on the Elk side. If you wish to control lighting via an Elk keypad button, you might try having that simply turn on an Elk output that ISY can read and then turn a scene on or off based on the status of that output.

[MWareman]

@madcodger

 

I think you have absolutely nailed it. Thanks. Knowing the history of where Elk came from has expanded my understanding of how we got where we are.

 

I'm with you. I think I'm simply not going to 'control' lighting from Elk at all - and simply have Elk adjust phantom outputs that ISY can respond to. It's a shame - it seems so 'almost there'.

 

To clarify - "control lighting from Elk" means from a button on a keypad, or from the 'Lighting' tab of a mobile application, or from the lighting screen of the web console. I do understand that from a rule works fine - since the rule does not need to get feedback of status.

 

Anyway - thanks. You really helped me 'get it'.

[madcodger]

Been there. Same frustrations. Happy to help.

 

It's a great combo, but you have to keep each unit's limitations in mind and work through/around them.

[Michel Kohanim]

Hi madcodger, thank you.

 

Hi Michael, I think we are talking past each other.

 

You cannot change the status of a light directly in ELK without changing its status in ISY. AND, in ISY, scenes do not have any states. AND, all your scenes have ONE controller. THUS, my suggestion is to just use the status of that controller as the status of your scene.

 

With kind regards,

Michel

[MWareman]

THUS, my suggestion is to just use the status of that controller as the status of your scene.

 

That would certainly solve the problem, and the feature request detailed is precisely aimed at having the ISY allow this. I currently cannot, on ISY, select any device to represent and report the status of the scene. I think it would be a useful feature - hence the feature request.

 

Unfortunately, the Elk does not let me do that either. Furthermore, the status of 'the' controller is not always relevant as there are often many controllers for a scene. However, there is only one scene responder that has a load connected (for the scenes I'm exporting). This is the device I need to get status from for the scene - not the controller.

 

The fundamental issue is that both 'scenes' and 'devices' are exported from ISY, but both are imported to Elk as 'devices'. From the Elk side, there is an apparent expectation that both behave the same. From ISY, we know they don't. This is why I think it is probably better if ISY does not let scenes get exported in the first place. Elk simply cannot deal with the concept of them.

 

At the end of the day, I think I'm going to not use lighting integration between the two - and keep all lighting control on ISY. Things are much happier that way.

[Michel Kohanim]

Hi Michael,

 

If I understand correctly, you want scenes to be removed from the export .. this is something you can do already. You can choose one, all, or none of the nodes.

 

With regards to scene status, I will have to digress ... if you look at all the previous posts for this feature, you'll immediately realize that it's an endless loop.

 

With kind regards,

Michel

[MWareman]

Hi Michel,

 

If I understand correctly, you want scenes to be removed from the export .. this is something you can do already. You can choose one, all, or none of the nodes.

 

While technically true, it's a royal PITA. A single alpha sorted list, without any kind of identification about which are scenes and which are devices. I have to rename all my scenes and prefix all with SC just so I could identify each. Far less than ideal. Please consider adding the folder tree to this dialog and some other identification of scene vs device here - at least. Maybe even put some text on the dialog to warn that scene status is not reported back to ISY- but device status is. Maybe also add a filter by radio button - filtering scenes by default. I could go on - but the ability to export scenes is the root of this issue and yes - I realize that simply removing the ability to export them will simply lead to 'why can't I export scenes' questions.

 

With regards to scene status, I will have to digress ... if you look at all the previous posts for this feature, you'll immediately realize that it's an endless loop.

 

That I know - hence my comment about taking a beating for bringing it up. I merely tried to come up with a possible solution that would add functionality that clearly a lot of people want - without annoying the other lots of people by making it both optional and not requiring everyone to change existing programming. Yes - it's a contentious issue. If we never revisit prior decisions, we never innovate a better product. Please believe me - this is what I'm trying to help you do.

 

Michael.