Custom/Raw Commands

[nstein]

I would like to request the ability to send custom or raw commands from programs, the rest interface and eventually soap.

 

Among other things this would allow me to set Operating flags, Control the beepers on the newest products, and other new features you haven't implemented yet, or might not get around to or have enough demand.

 

I can do some of it right now using a separate PLM or PLC but it is annoying having to use another one and a terminal when I could do it through a program or rest:

 

For example /rest/

/cmd/raw/0x30/0x01 could trigger the beeper on the newest keypads.

 

Thanks,

Nick

[Michel Kohanim]

Hi Nick,

 

Historically, we have shied away from this request mostly because the same raw commands could alter the database and hence increase our support issues. i.e. YOU cannot guarantee that the commands your customers use is not going to have an adverse impact on the device itself.

 

I think a better solution would be to let us know precisely what features are missing and we'll implement them within our managed framework.

 

With kind regards,

Michel

[nstein]

Thanks Michel,

 

I understand your point, and I plan on making more suggestions, I would prefer to have them implemented in your framework, but that takes time, and might not always get implemented.

 

Would it be possible to have hidden advance controls that are not supported and suggested only for power users. Ideally users will not use this feature unless they know what the command does, and it might even be hidden by default.

 

Advanced users are still taking the chances by using additional PLMs, its just more of a pain; Which I guess does reduce the likely hood.

 

With the new SmartLinc revision I think I can do this with ISY using web resources, but I rather do it directly through ISY and a little less raw, they make you specify the raw PLM command.

 

I my opinion this is one of the biggest draw backs to ISY; having to wait for everything to be supported, there is no workaround, there is no real compatibility for unsupported devices; UDI does a more than good job of responding to users requests but No matter how hard UDI tries there will always be something missing.

 

Thanks,

-Nick

[Michel Kohanim]

Hi Nick,

 

You are 100% correct: no matter how hard we try, there will be a) a lag between new features and what we implement and our list of features to implement might not necessarily reflect all the features that are requested by users.

 

Unfortunately, allowing uncontrolled access to INSTEON commands is very similar to opening ISY for viruses: the problem is not the power user but the malicious user who takes advantage of this feature to simply be malicious. This will create frustrated customers and support issues.

 

The best thing to do would be to list the top 5 most important features since, we always go through the INSTEON docs but, as you have noted, our list of important features is NOT the same as yours or others for that matter.

 

With kind regards,

Michel

[nstein]

Maybe it should be optional; It is like locking down windows completely with no option to disable it if we want to take the risk we should be able to. Does UDI need to be an over protective parent?

 

I wouldn't call it uncontrolled access as ISY requires a password.

 

And you won't like to hear this but in my humble opinion this is on the top 5 most important features even if it is not the most used.

 

Is there a way to allow this as an option for the less security conscience costumers, as it seems overkill to me.

 

Hypothetically, could they do much more damage then through the admin console?

 

Thanks for taking the time to discuss this,

 

Edit: Of course operating flags is also on the top 5, but I know you (UDI) are looking into that.

 

Nick

[Michel Kohanim]

Nick,

 

You are missing the point. The point is: assume you are the malicious developer. You develop an application and users buy into it (just like your ISYAjax). How would UDI guarantee that your application is NOT malicious? Who will be dealing with unsatisfied/frustrated customers and support? With this feature, your ISYAjax can simply wreak havoc on the whole INSTEON network deleting links, adding links, changing memory location values, etc. This has nothing to do with protective parent but to do with configuration integrity via a controlled environment.

 

As far as 5 most important features, I meant those that you need out of INSTEON devices. This way, we can give you what you want without opening up the whole INSTEON protocol to everyone.

 

With kind regards,

Michel

[nstein]

This can be done right now, not through rest but trough TCP/IP, you can't change raw memory but you could still do almost as much damage, just by changing scenes.

 

Would UDI guarantee it? In most environments there a few extras certified safe, and most just presumed safe because no body complained, the user watch dog effect.

 

What I am asking is how can we shift the responsibility and decision to the customer (me), instead of UDI. If I want to open up my ISY I should be able to, that is closer to what I meant by protective parent.

 

 

 

So you are proposing 5 commands, that are safe enough to open up? For the most part would there be a point beyond implementing them in the nicer framework if it is that limited, I suppose it could be to any device which would be beneficial. But not a raw command as much as a unlocked control, with a raw parameter or action, but I think they are raw or or close to it (at least in rest, programs would be another question).

 

In which case one could be the raw setting and reading (if possible) of operating flags, for any device.

 

Another feature, maybe not this way would be get engine version; It would be nice to be able to see the engine version for any device (I1 or I2).

 

Something should be done with the beeper but I wouldn't consider that much of a raw command with only 0x30 0x01 no options, a simple BEP control would work, and adding it to programs.

 

-Nick

[Michel Kohanim]

Hi Nick,

 

I am not sure I follow what you are saying: how could changing scenes in ISY be as damaging as allowing one to change any memory location in any device? Please note that ISY keeps track of everything that's done to a device and thus can be reverted back by using a restore. With raw commands, ISY is not in the loop and thus restore will never work. In Admin Console there are no functions that allow for setting memory locations of unknown functionality.

 

And, again, I am not worried about the customers. I am worried about developers misusing this feature and the customers not knowing what happened. And, it's not in UDI's philosophy to bounce customers from one developer to another to find the root causes. So, at the end of the day, UDI will be responsible for whatever application is running on/against ISY.

 

I shall take the other suggestions into consideration for our next release.

 

With kind regards,

Michel

This can be done right now, not through rest but trough TCP/IP, you can't change raw memory but you could still do almost as much damage, just by changing scenes.

 

Would UDI guarantee it? In most environments there a few extras certified safe, and most just presumed safe because no body complained, the user watch dog effect.

 

What I am asking is how can we shift the responsibility and decision to the customer (me), instead of UDI. If I want to open up my ISY I should be able to, that is closer to what I meant by protective parent.

 

 

 

So you are proposing 5 commands, that are safe enough to open up? For the most part would there be a point beyond implementing them in the nicer framework if it is that limited, I suppose it could be to any device which would be beneficial. But not a raw command as much as a unlocked control, with a raw parameter or action, but I think they are raw or or close to it (at least in rest, programs would be another question).

 

In which case one could be the raw setting and reading (if possible) of operating flags, for any device.

 

Another feature, maybe not this way would be get engine version; It would be nice to be able to see the engine version for any device (I1 or I2).

 

Something should be done with the beeper but I wouldn't consider that much of a raw command with only 0x30 0x01 no options, a simple BEP control would work, and adding it to programs.

 

-Nick

[nstein]

Thanks Michel,

 

There doesn't seem to be much demand for this anyways, and I am disappointed that the feature can't be added but I understand your predicament; I would hope developers would use the feature responsibly and only when needed, but there is no guarantee, that you require.

 

Thanks,

 

Nick