Announcement

Collapse
No announcement yet.

Custom vs Native

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Custom vs Native

    Michael,

    I've been waiting for some time for Ken to deliver a beta of the Temp05 plugin for V5. I'm on the verge of dumping the Temp05 plugin and going to your native Temp05 support so I can at least install my V5 upgrade chips. The only thing yours doesn't do right now that his does, is control the Relay05, but since I don't have that in production yet it's not really a problem.

    Am I the only "Custom" user right now? Do you need me to stay as I am to test the Custom interface, or would you prefer to just drop it?

    --Bill

    #2
    Its your call with respect to which approach you wish to use to collect data. I believe the other Bill is also using the Temp05 plugin.

    What this really sounds like it a volunteer to design what the Relay interface should look like and one to evaluate its operation. .... now you may think twice about switching.
    Based upon what I see of the Temp05 interface for relays I do not see much risk in implementing the relay interface.

    I do not have the Relay05 and with my ocelot's I/O module I have no need to go down that path. I have a place for it in the Temp05 setup tab. I thought about a scripting interface as well as a virtual device / plugin device mapping, but really whatever fits best in your environment will likely be best for any other users that may need this capability.

    Comment


      #3
      and put them back together in order to make the switch, so I'll put it off a few more days. I'd be happy to be involved in testing the relay functionality, though.

      The device has 8 DPDT relays. I agree that you should support a scripting interface as well as virtual device controls. I think it would be nice to support a "momentary" relay closure as well as simple "on" and "off" (one of my applications would be a garage door opener momentary push-button). Maybe each relay could be set to support momentary or not, and if momentary, how long between close and open. On the setup tab, a column of relay numbers 1-8, device codes, description/name (for the device), a check-box for momentary, and a duration (if momentary). I'm not sure what the controls for this should look like - probably just On and Off regardless, even though the Off wouldn't be useful for a momentary device.

      I'll let you know when I switch to native mode.

      --Bill

      Comment


        #4
        I've got a RELAY05 and I will need support for it as I'm intending to ditch all the other scripts etc I've been using and just rely on you plug in, Michael.

        So count me in as a tester. Biggest problem I can see with RELAY05 is that it seems to have a fixed function where the relay goes off after nn (where n= 0 to 99) minuites. I'm sure Mitch has some solid logic behind this, but it could be a problem with some types of device if you don't retrigger it before it goes off.

        Comment


          #5
          Duncan,

          The timer for the Relay shut-off was added for users that wanted the safety feature for use with sprinkler systems. If you don't need it, set the timer to 0 and the relays will not shut off unless commanded to by a RLY command.

          Mitch

          http://www.midondesign.com
          http://www.midondesign.com

          Comment


            #6
            Mitch,

            Thanks - that's cool

            .... but why does TEMP05 say input "1-99 mins" ?

            I guess we'll just call it an "undocumented feature", well until this moment, that is !!

            Duncan

            Comment


              #7
              I, too, am considering the switch because of the delay of the V5 TEMP05 plug-in. At the moment all I have are weather sensors, but I do want to look into some of the other 1-wire devices. I'm just not sure if its worth waiting for the TEMP05 plug-in, or not.

              Bill

              Comment


                #8
                I used Ken's plugin for a while, but then saw Michael's plugin taking on so much functionality, I decided to go native. Haven't looked back. Running Temp05 V5 with no problems. Michael is even removing the limitation on the number of devices (used to be only 2 humidity devices and 20 temp sensors). I have no interest in the Relay05 (I have the Ocelot/SECU combo), but I can see that adding that functionality would pretty much negate the need for Ken's plugin if you are already using this plugin.

                Comment


                  #9
                  Anybody here old enought to remember that one?

                  I've successfully switched over to V5.00 and native Temp05. It took some fiddling around to get it working. Maybe I was just too impatient, but after manually issuing the INI and setting the interval it started logging new data. There are no obvious problems.

                  --Bill

                  Comment


                    #10
                    Bill,

                    Cigarettes, but I do not recall which one.

                    Would your fiddling experiences indicate that the plugin should be doing something that less experiences users could benefit from?

                    As a curiosity, did you use the virtual devices allocated for the Temp05 Plugin or did you use others that are in the standard homeseer allocation?

                    Comment


                      #11
                      if I can't come up with the details myself. I was in High School, so I should remember - maybe Pall Mall? I don't know.

                      I didn't change the device codes that were already set in the ini file. I just removed all of the devices, using the button provided in the Temp05 plugin, then removed the plugin, then checked the "use" box in the mcsTemperature setup and filled in the comport number and (5 minute) interval and saved it, then restarted Homeseer. After 15 minutes of no new entries, and the debug display just counting down the time over and over, I started fooling with it - sending INI and SET commands. I couldn't get any data back that looked useful. I finally determined that I had the little memory chip backwards and after I switched it around the INI and SET commands produced real-looking results. I still couldn't set a value in the Cal bias fields, and it took another 10 minutes before the first data posted to the database, and then the serial numbers showed up and the Cal bias worked, and everything was fine.

                      I'm pretty sure I didn't have the setup dialog open when it was receiving data.

                      What I expected was that by setting the interval and comport I would give the plugin enough information to go and dialog with the Temp05 - tell it the interval, get the attached devices, etc. - and I wouldn't need to do any of that stuff. It did set up the virtual devices (with their old House/Unit codes, but not their old names). By sheer luck, I assume, the devices came out in the same order they were in before, so R1 was still the old R1, etc.

                      I thought plugins were supposed to get their variable "house" codes from Homeseer, so it surprised me that it kept the "\" that was in the ini. I fully expected that to change when the plugin started up. I think "native" mode device codes should be assigned by the plugin, and "custom" ones honored by the plugin. Maybe I'm brainwashed by the Temp05 and Doomotion plugins.

                      I guess if the user is supposed to keep hands off the Temp05 (e.g. INI and SET) then you probably should say so explicitly somewhere, and if they have to do stuff, then they need to be told that. I know a lot of people have been confused about the old V2 scripts (i.e. whether to keep them or remove them), and that's the same sort of thing - it's easy for people to make unwarranted assumptions based on their own particular experience (or lack thereof).

                      I'm not suggesting that you shouldn't let people have access to cool diagnostic tools - but it probably should be clear whether they are diagnostic or a routine part of setting things up. I guess I'm still not sure whether things are running well now because of or in spite of my fooling around.

                      --Bill

                      Comment


                        #12
                        Bill,

                        I think it was Tareyton, and the slogan was "I'd rather fight than switch", and the people in all the ads had a black eye. I forget the PallMall slogan. The other one that has stuck in the back of my head is "its a silly millimeter longer" but I can't remember which brand that was. And then there was "I'd walk a mile for a Camel", or something like that.

                        Anyway, back to the thread topic. I switched last night. I just couldn't stand looking at the V5 chips sitting there any longer.

                        I, too, was a little confused by the house code, I still had it set to the TEMP05 plug-in code. I did change it to "R", which I think is the default. But I had the same question about plug-in house code vs. "regular" house code. It took me a little fumbling around to get the sensors defined correctly, but I did. I had to go in and manually edit my database to get the data in the right place, I had changed field names and they got added, but all the old one's remained. I deleted all the empty columns and renamed the Rn columns to the new names. It is all working now and I didn't lose any data. I did not have to tweak the INI file at all.

                        I did the INI first using a terminal program. I was confused also about that direct access window. But I went ahead and did the INI again in the window, and the SET.

                        Like you, I am not sure whether I got lucky or fumbled around just enough and did some of the right things to get it to work. But its working!

                        Bill

                        Comment


                          #13
                          The only one of those that did what they wanted (made you remember the brand name) was the Camel one. All the rest have faded to a dim memory with brand names detached (at least in my memory). Now I'm going to waste days trying to remember which one was a millimeter longer...

                          I didn't want to use up the R housecode, and I assumed the plugin was going to assign (or be assigned) its own non-alphabetic housecode, so I just left what was there to see what would happen. Now I'm concerned that some other plugin will try to take over the "\" housecode and mess things up.

                          --Bill

                          Comment


                            #14
                            Michael,

                            Bill's experience sounds pretty close to my own when I added sensors, so it definitely is repeatable, although, because of the trial-and-error method of getting it to work, we can't exactly tell you how we got things working.

                            Comment


                              #15
                              Thank you all for sharing, Maybe the intall instructions should be to "fumble around and it will magically start to work". That is what seems to work for everyone. Seriously, though, the input is appreciated.

                              As far as house code usage...

                              A plugin has the privledge of creating one or more new house codes. Homeseer remembers the last one that was given out. When it is given to the plugin the plugin is then responsible for remembering what code it was given. This is usually done by placing it in the registry or in an .ini file.

                              Whenever a device value or status (I forget exactly) changes then homeseer calls each and every plugin to see if needs to do anything because of this event. The first thing the plugin is suppose to do is see if the device code that is experiencing the event is one that it is concerned about. This is typically a check to see if the device code is the same as the one that it requested some time in the past, but it need not be. If it not of interest then the plugin just returns back to homeseer. If it is of interest to the plugin then the necessary actions are taken before returning to homeseer.

                              If all plugins behave then there will never be a problem with device code "\" since the only plugin that should do anything special with it is Temp05 Plugin. If you reinstall Temp05 plugin then it should restore its memory of which house code it was using. If you do not reinstall it then no other plugin will intentionally try to use it so it just becomes another general house code such as "R".

                              If I was going to make the transition between the Temp05 plugin and mcsTemperature plugin, then I would just leave the house code alone and use the "\" or whatever the Temp05 plugin was using. Sometime in the future the mcsTemperature plugin will start to manage its own house code. At that time then the benefits of creating a new one vs using an existing one will need to be understood and the appropriate decision made. The downside to continuing to use the "\" is that you need to remember that it is the one associated with an uninstalled plugin.

                              Comment

                              Working...
                              X