ADIOcelot Plugin

[Clever1]

Any idea why I wouldn't be able to run the setup function either from the config option in setup or the setup function from the drop down area on the window menu for HomeSeer? I migrated from the other Ocelot plug-in some months ago and have never been able to get the setup option to work. Now I am attempting to make some forward progress with my IR and I need the setup capability.

Hi guys<o></o>
<o></o>
Any progress with the new ADIOcelot plug-in<o></o>

1.14.0.10 plug-in


1021

[Jim Doolittle]

I have been sitting on the sidelines wondering if my system was affected because my garage door sensor connected to Ocelot was not working correctly. Seemed to happen when I upgrade to HS 2.3 but have been busy making sure all my own plug-ins were baheving well with HS 2.3. Installing new ADIOcelot build now.

[stevea]

I deleted the relay devices, installed new version 1.14.0.10, created devices again and evewrything seems to be working.
Thanks Michael!!!

Yes, thank you Michael.

Steve

[Michael McSharry]

The most current versionof the plugin is at the top of this subforum. Download,stopHS, unzip into main homeseer folder to replace previous hspi_adiocelot.ocx

[pacopic]

I am having the same exact problem with HS 2.3. and I am using 1.14.0.3 version. How can I download 1.14.0.10 version?

[Czechmarty]

I deleted the relay devices, installed new version 1.14.0.10, created devices again and evewrything seems to be working.
Thanks Michael!!!

Marty

[Rick Tinker]

Michael,

I missed where you mentioned you are using all Long Integers, and I did not look at the code until now.

The issue is likely then to be related to a change in hs_compatibility.exe or something else - as I mentioned before, I am not sure when/where the change was made, but I am not doubting that a change at our end was the catalyst.

However, I am trying to get this moving forward, and that means correcting the situation in a one-time fix. That is, providing there are no places where it goes through a 16 bit integer, then we only need to get the value back to its proper place.

This happened with 1-2 users and the Compose plug-in. Once they changed to using the .NET plug-in so that it would not go through a 16 bit integer, they still had to fix the device, and that was done by deleting it and re-creating it, which is what I was suggesting here.

[Michael McSharry]

I guess I'm being dense on this. The VB6 plugin passes the Long value 00008000 as a 32 bit value to HS in the .misc value of a DeviceClass. HS then saves this to the datbase as 80000000 and then retuns it to the DeviceClass.misc in this same manner so the SETIO bit it OFF.

What does a VB6 plugin need to do so the SETIO bit is maintained as HS saves the .misc property to the database?

All the values that are being used within ADIOcelot are declared as Long so if HS has also declared .misc as .NET Integer (32 bit) then there should not be any sign extension. If HS has declared .misc as .NET short (16 bit) then the upper 16 bits of the value from ADIOcelot will be truncated and the 8000 will then appear as a negative number.

I did post the related code from the plugin earlier in this thread. What needs to change so SETIO bit will be maintained?

[Rick Tinker]

Michael,

Speaking strictly in VB6/16-bit terms:

An integer uses the 16th bit to indicate positive/negative. Thus, 8000 is -32767 or something like that. When this is passed as bytes or anything where the 16th bit is just another bit, then it works fine. However, it is stored in the database as a signed value, and so it is written as a negative integer and then read into a long integer, so the sign is retained. In the case of &H8000, it becomes &H80000000 because the sign bit is now the 32nd bit instead of the 16th bit. This means that the SetIO bit is turned OFF just through the act of passing this value through different sized variables.

[Michael McSharry]

While I do not think it will make any difference I did remove the "0 OR" from the expresssion where the .misc property is set. It is posted as V1.14.10. I dont know why the rev went from .4 to .10 as I do not recall activity on this plugin.

Even if there is an issue of FFFF8000 vs. 00008000 (short vs. long) I do not see why it would make any difference to the operation of the plugin as the "8" bit is the one that affects the SETIO call and it is set in both cases. The only rationalization I can come up with is that there are other undocumented bits in the upper 16 bits that would take priority or HS is not expecting a negative number and this results in unexpected behavior.

[Rick Tinker]

Delete the devices and have the plug-in re-create them. If there are no more problems with Integer(Long)-Short Integer(Integer) then it will work fine.

[stevea]

Michael would and did get the same response as you on this issue.

Well, since I got no response at all (help desk ticket 18321) except for Rupp asking for the URL to this thread, I guess saying Michael gets the same response doesn't feel too good. If I read your message, you say developers should be using a long int for MISC, and if I read Michaels two messages earlier, it sounds like he thinks he IS using a long int. It sounds to me like everyone thinks its not their problem, so my guess is it stays the way it is. Oh well.

Steve

[Rick Tinker]

Michael would and did get the same response as you on this issue.

Apparently a change was made somewhere in the 2.3.0.0 development to cease the use of short integers. None of us can recall making it and it was too minor for it to have appeared in our check-in notes, and for a few reasons we are not going to go back through the history to see when and who made the change.

The change is needed because there are MISC values that exceed the size of a short integer. We have already established that we had very poor beta testing with this release, something we are working on to address with future releases, but if it had been brought to our attention earlier, we would have written a conversion program rather than reverse the change.

Furthermore, we have no control over 3rd party plug-ins, so even if we refer to MISC with an Integer now, a plug-in that still uses a Short Integer (Integer on a 16 bit plug-in) will continue to create and work with the devices incorrectly. The documentation on the DeviceClass shows that the MISC property is a Long Integer, which is an Integer in HomeSeer, so even that reflects what it should be.