In a polling thread it was mentioned that Machine to Machine communications with different HS clients would be a means to take advantage or existing plugins within HS2 and still use HS3 even when those plugins are not being ported to HS3.
mcsXap exists for HS1 and HS2 and was working with the Dec'2012 version of HS3. This provides a mechanism to communicate at the device level which I believe is what most do use in HS.
As an example, let us assume ACRF plugin will not be ported to HS3 or at least not initially, but it is an important part of your existing setup. ACRF populates HS2 devices based upon received RF sensor information.
With mcsXap any or all of the ACRF virtual devices can be mapped onto the LAN via xAP so that any change in the device made by ACRF will be transmitted over the LAN where any other xAP-cognizant software or hardware can recognize the deivce change. In the case of HS3 these ACRF devices that are now on the LAN via xAP will be seen by HS3 plugin mcsXap and equivalent devices will be updatd on HS3 to reflect the changes that have been made by ACRF to HS2 devices.
The same can be done in the other direction where you want HS3 to affect an output device that is the Direct IO Connector plugin in HS2.
The communication model provides for sharing of DeviceStatus, DeviceValue and DeviceString which are the things most users interact. DeviceStatus is no longer used in HS3 and some mapping logic was used in HS3 version of mcsXap due to the depreciation of DeviceStatus in HS3.
xAP protocol is extensible and other other information beyond just these three device properties could be communicated in a similiar manner. A schema that is more closely aligns with Zwave is possible or one that supports music transport. There are definitions for these in xAP but mcsXap has only implemented the generic model that was exposed by HS with string/value/status.
mcsXap for HS1 and HS2 also provided event sharing as part of exposing most of the HS internals. For HS3 I did not port that part of mcsXap. I do not think I ported the capabilty to remotely execute the API defined by HS for scripting, but that also was not something that had seen much use. There are a few special schema that likely got ported such as X10, Weather Report and the HS Log. In the HS log example, it will allow the HS2 log to be merged with the HS3 log and viewed via normal mechanism within HS3. The reverse could also be done if one wanted to retain HS2 as the primary place where logs are maintained.
mcsXap exists for HS1 and HS2 and was working with the Dec'2012 version of HS3. This provides a mechanism to communicate at the device level which I believe is what most do use in HS.
As an example, let us assume ACRF plugin will not be ported to HS3 or at least not initially, but it is an important part of your existing setup. ACRF populates HS2 devices based upon received RF sensor information.
With mcsXap any or all of the ACRF virtual devices can be mapped onto the LAN via xAP so that any change in the device made by ACRF will be transmitted over the LAN where any other xAP-cognizant software or hardware can recognize the deivce change. In the case of HS3 these ACRF devices that are now on the LAN via xAP will be seen by HS3 plugin mcsXap and equivalent devices will be updatd on HS3 to reflect the changes that have been made by ACRF to HS2 devices.
The same can be done in the other direction where you want HS3 to affect an output device that is the Direct IO Connector plugin in HS2.
The communication model provides for sharing of DeviceStatus, DeviceValue and DeviceString which are the things most users interact. DeviceStatus is no longer used in HS3 and some mapping logic was used in HS3 version of mcsXap due to the depreciation of DeviceStatus in HS3.
xAP protocol is extensible and other other information beyond just these three device properties could be communicated in a similiar manner. A schema that is more closely aligns with Zwave is possible or one that supports music transport. There are definitions for these in xAP but mcsXap has only implemented the generic model that was exposed by HS with string/value/status.
mcsXap for HS1 and HS2 also provided event sharing as part of exposing most of the HS internals. For HS3 I did not port that part of mcsXap. I do not think I ported the capabilty to remotely execute the API defined by HS for scripting, but that also was not something that had seen much use. There are a few special schema that likely got ported such as X10, Weather Report and the HS Log. In the HS log example, it will allow the HS2 log to be merged with the HS3 log and viewed via normal mechanism within HS3. The reverse could also be done if one wanted to retain HS2 as the primary place where logs are maintained.
Comment