Just got this device. I'd like to use it but the plug-in conflicts with my ACRF2 plugin.
The house code the ADIO-100 wants to use is "[". (Hardcoded?) This conflicts with what ACRF2 selected almost a year or so ago when I purchased it.
Changing my config on the ACRF2 plug-in is a lot of work - about 30 devices + graphing objects I'd need to update, not to mention events.
Specifying a different house code in the M100.ini file gets over written with what the ADIO-100 plug-in wants to use.
Please modify the plug-in to READ the ini file at startup. Specifically, the "code=" and "offset=" keys under [Module x]. Where x is the module number. Maybe it is supposed to and it does a write instead of a read.
I mention this because even when the ADIO-100 plug-in finally picks devices under the house code that aren't in use, it still screws up some of the devices in ACRF2. It may be another bug - but the devices that the ADIO-100 plug-in screws up are all under [17. Meaning, I believe the plug-in is still associating with device ID's 1-16 even though the plug-in created new devices at different ID's.
Example - ACRF2 for some reason picked [4 as the first device (itself) and all sensors come after that. The ADIO-100 Plug-in made device [1, [2, [3, then jumped to [44, [45, [46...[56. The virtual device creation worked, but seems the status updates still go to devices [1 - [16.
Guess I'll make the first part a bug report. Think I can fix the second part by changing the device [4 to [1. Wonder if this will make the ADIO-100 plug-in pick a different house code, too?
The house code the ADIO-100 wants to use is "[". (Hardcoded?) This conflicts with what ACRF2 selected almost a year or so ago when I purchased it.
Changing my config on the ACRF2 plug-in is a lot of work - about 30 devices + graphing objects I'd need to update, not to mention events.
Specifying a different house code in the M100.ini file gets over written with what the ADIO-100 plug-in wants to use.
Please modify the plug-in to READ the ini file at startup. Specifically, the "code=" and "offset=" keys under [Module x]. Where x is the module number. Maybe it is supposed to and it does a write instead of a read.
I mention this because even when the ADIO-100 plug-in finally picks devices under the house code that aren't in use, it still screws up some of the devices in ACRF2. It may be another bug - but the devices that the ADIO-100 plug-in screws up are all under [17. Meaning, I believe the plug-in is still associating with device ID's 1-16 even though the plug-in created new devices at different ID's.
Example - ACRF2 for some reason picked [4 as the first device (itself) and all sensors come after that. The ADIO-100 Plug-in made device [1, [2, [3, then jumped to [44, [45, [46...[56. The virtual device creation worked, but seems the status updates still go to devices [1 - [16.
Guess I'll make the first part a bug report. Think I can fix the second part by changing the device [4 to [1. Wonder if this will make the ADIO-100 plug-in pick a different house code, too?
Comment