Eureka!

[ekuykendall]

Michael,

I got some time to really dig into my problems with the plugin. Here is what I found.

1. The reason that my second temp sensor (R2) is not being recorded is because it has the same OW sensor ID as the humidity sensor - it is built into the same physical package, and Temp05 V5 pulls it out as a sepearate temp sensor. Your plugin maps virtual devices to these OW ID's in the INI, so it looks like only one virtual ID can take that slot. Thus, while Temp05 happily reports data on R2 in HS, MCS ignores it in the DB and ASPs. This is not a huge problem, as I have plenty of other sensors. Just more of annoyance really, as I would have liked to use that reading.

2. You never told me to try this, but I noticed that several other folks deleted their INI file and had the plugin setup regenerate it. I tried this, and voila - everything works now - the forecast part of the Temp ASP, the sensor mapping pages, etc.

3. I still think there is some funny business going on in the mapping - extra sensor ID's that aren't real, sensor readings from sensors that don't exist, etc. But once I hide those annoyances from view, they are no longer a problem (they don't appear on any charts or logs. So, these don't bother me - they're just bugs for you to track down!

4. I will now be able to set the calibration bias and see how that works. Will also hammer on the trigger controls - I notice nobody has commented on those at all since I've been on this forum.

[ekuykendall]

Crazy timing - I put out the previous post just as you were releasing 3.3.3 with a note to "regenerate your INI files". I am loading it (3.3.3) as we speak, and will proceed with testing as described above.

[ekuykendall]

Michael,

OK, after a cursory glance at 3.3.3, I tried to change the calibration offset feature before hitting the sack. It doesn't seem to be working, but then I may be setting it up wrong.

I assume the calibration field is configured for +/- values, so if I want to drop a sensor reading by 2 degrees, I should enter "-2" in the calibration field for that sensor? The raw Temp05 readings remain the same (as I would expect), but the HS display, DB, and ASP do not show the offset. Is this feature enabled in 3.3.3?

Also, just as a spellcheck item for you, you have "delimited" spelled "delimeted" everywhere it is used.

Gotta call it a day (it's already morning - ugh!)

[Michael McSharry]

The last time I actually tested the calibration was before all my changes on internal device mapping. You are correct that the logic flow is raw data comes from the sensor, the calibration bias is added to it, the English/Metirc conversion is applied, then stored in the virtual device and later into the database from where the ASP page data is generated.

Since the Temp05 delivers the same sensor serial number for both temperature and humidity I need to recognize this condition as I'm building the internal tables. Its not a big deal.

I suspect I will just include the sensor type information as part of the lookup criteria and all should work fine. I may end up doing something similiar for the wind gust where both wind speed and wind gust are associated with the same wind speed counter.

I'm bouncing back and forth as to the best way to handle the computed devices for rain rate, high wind, and future baro trend. One approach is to define a class of computed virtual devices with user specification of the virtual device as is now done with the high wind on the Devices tab. The other is like the wind rate which is defined as a device type on the Weather tab. Both approaches are extensible, but I want to settle on only one to minimize user confusion and dissimiliar logic within the plugin. Any opinions as to which is more intuitive to the user?

[This message was edited by Michael McSharry on Thursday, 23 January 2003 at 08:01 AM.]

[bwawsc]

In order to prevent fighting over variable codes, doesn't HS "assign" a housecode to each plugin? When you're using another plugin's data, as in the case of the Temp05, it makes sense for the user to specify the housecode and tell you which unitcode is which. For devices that are unique to mcsTemperature, I'd expect you would assign your own without user intervention (but only if needed - if no wind, baro or rain devices are specified, obviously you don't need devices to compute related values). I don't know if this helps or not - just an observation. It strikes me that the fields on the Devices/Files tab (default housecode for new sensors and default location for new sensors) shouldn't be user-enterable unless the user really gets to specify them. I would assume if mcsTemperature gets a new housecode (maybe as a result of being removed and re-installed?) you would have to go through and remove/replace your previous virtual devices/variables. I saw DooMotion and Temp05 housecodes change as a result of an upgrade to Temp05 plugin from 0.0.6 to 0.0.9, and this resulted in some fighting between them over devices.

--Bill

[Michael McSharry]

Bill,
I addressed this same potential problem to Rich when I first starting working with the Plugin SDK. His resonse indicated that once a plugin is assigned a code that it retains that code forever. It will never be given to a new Plugin. It is, however, the plugin's job to remember which house code it was given. The SDK shows it being stored in either an .ini file or the Windows registry by the plugin. If the plugin changes its name (e.g. Temperature vs mcsTemperature) then it will get a new house code assigned, but the old one will not be assigned to any other plugin. I think there are some 40 or so plugin house codes available. With the rate plugin are being introduced that should last through the end of the year if we are lucky. After that the house code scheme will need to be extended.

You appear to be indicating that something is broken in this process and the same housecode was used by multiple plugins. While Rich provides a unique house code, it is the plugin developer's responsibilty to use the one that was assigned to the plugin. Likewise it is homeseer's responsibility to provide unique house codes.

Other than this difference I agree with your strategy about the house code / device code for mcsTemperature.

Do you have any leaning with respect to how something like Rain Rate should be handled. Should it behave like it is a sensor of type Rain Rate, or should it behave as a special device containing a computed value based upon other sensor information? Should the Temp05 version info be a special virtual device or a "Version ID" type of sensor? My thinking at this instant is that any item that is a candidate for database store & temperature.asp should be a sensorType. Over time with the introduction of new computed infomation, however, the distinction between graphable and non-graphable may become unclear.