User definable device control blocks

[larryllix]

Is there a way that user could enter parameters into a device control block/descriptor, of some kind, so that new devices could be supported by users and the DCB tables passed around?

 

This would take some doing on UDI's part to create the plug-in DCB tools like editor, ISY plug-in  API, secure loader etc. but it could save UDI some time in creating and supporting some of these new devices coming out.  It seems like the HA field is beginning to explode with all kinds of new gadgets and this could help UDI stay at the top of the supported list and the top of the HA preferred devices in the market.

 

I am sure some of us OCD users would love to create some of their own support for devices, even if it  is to adapt the DCB to the latest firmware twist that Insteon put out or add some invisible parameter call not currently supported by ISY that wasn't supplied in the formal API. Of course along with this there would need to be an acceptance and approval/voting/rating process for users to a adapt good DCB inputs  as the ISY standard and promoted "device control" interface.

 

Kind of like "Open Source" device support. The market likes that right now.

 

 

[Michel Kohanim]

Hi larryllix,

 

I am not familiar with DCB. We are working towards more generic/virtual/user-defined devices in 5.0 though.

 

With kind regards,
Michel

[larryllix]

DCB (Device Control Block) was an old term used in some O/Ses full of parameters that each driver used. So in a MsDos system the :a: floppy, c:, d:, e:, HDD DCBs would set the different parameters for each drive. ie. stepping rate of the read/write head, device name, data bock size, data block memory location, current head location, buffer location, etc.. etc.. but the driver software was re-entrant, multitasking and all users and devices used  the same software piece for every block or sequential access device.

 

Now to compare that with Insteon usage many different basic types would need drivers,  I would be sure, but many of each types/styles could share some driver(s) firmware but use a separate DCB to set which driver and parameters for each device..

 

The v5, you describe,  sounds similar in function.

[Michel Kohanim]

Hi larryllix,

 

Thanks so very much for the details. Yes, v5 should be similar. I just cannot wait to be done with Z-Wave so that we can move on.

 

With kind regards,
Michel

[larryllix]

Hi larryllix,

 

Thanks so very much for the details. Yes, v5 should be similar. I just cannot wait to be done with Z-Wave so that we can move on.

 

With kind regards,

Michel

Having none...me too!

Projects always seem exciting and fun at first then when the last 10% is 90% of the work it becomes a bore. That's the main reason all us old hackers are not producing a ISY995i like you guys are!

 

The documentation on most of this stuff is so bad that it puts UDI "above the rest" (not the  interface protocol either )

[Michel Kohanim]

Hi larryllix,

 

Thanks so very much for the compliments. It does mean a LOT to us. Z-Wave is a very sophisticated protocol with too many permutation of variables that can make things either work perfectly or not at all. It's been quite taxing (to say the least).

 

With kind regards,
Michel