get_conditoin always returns false

sirmeili commented 7 years ago

Summary

get_Condition always returns false. This means that you can never tell when trigger is being used as a condition.

Expected Behavior

I would expect HSPI to not override get_Condition as this should be set by Homeser and not by the plugin (it's a property: See here: https://homeseer.com/support/homeseer/HS3/SDK/condition.htm

get_Conditon() should return true or false depending on how the trigger is currently being used.

Current Behavior

Currently, get_Condition always returns false.

Possible Solution

Remove get_Condition from HSPIBase and HSPIBase2. I'm not sure how this will work with inheritance, but we need to let HomeSeer determine it.

Steps to Reproduce (for bugs)

Create a trigger, in TriggerBuildUI you can use Console.WriteLine() to out put get_Condition(triggerInfo)

You will see that no matter how you use it (as a condition or a trigger), it will always output false, which is incorrect.

Screenshots (if appropriate)

Context

This prevents me from creating a condition that is not used as a trigger. I have to have this to determine how the trigger is being used in it's current context. If it's not a trigger, I need to not return anything. If it is a trigger, I need to show my options (in TriggerBuildUI).

Your Environment

HomeSeer version: 3.0.0.318
HomeSeer operating system: Windows 10
HSPI version: 1.0.42
Template version: 1.0.0
Developer environment: VS2015 community

Checklist

[* ] I have read the CODE OF CONDUCT document.
[* ] I have searched

alexdresko commented 7 years ago

@sirmeili, HS will call set_condition when a trigger is being used as a condition, not get_condition. If you want get_condition to return the value provided by HS, you'll need to override both set_condition and get_condition in your plugin to set and get a field level value.

Think of the get_* and set_* methods as C# property getters and setters. Except, because HS is written in VB.NET, the conversion to C# gets messy. One of the main goals of HSPI to hide all of that VB.NET craziness, but I haven't had time to implement that code. It's on the radar.

I don't know enough about HS plugins to know if UID is the correct key to use, but here's one way you might implement the get and set...

        private readonly Dictionary<int, bool> _conditions = new Dictionary<int, bool>();

        public override bool get_Condition(IPlugInAPI.strTrigActInfo actionInfo)
        {
            return _conditions[actionInfo.UID];
        }

        public override void set_Condition(IPlugInAPI.strTrigActInfo actionInfo, bool value)
        {
            _conditions[actionInfo.UID] = value;
        }

Please let me know if that works, as that will help me know how best to implement those properties (think HspiBase3 maybe?). HspiBase3 would simply have a Condition property that does the get/set dirty work for you.

I found a bunch of set_condition implementations on github (https://github.com/search?p=1&q=ipluginapi+set_Condition&type=Code&utf8=%E2%9C%93) but only one of them actually did anything besides ignore the value... https://github.com/geoffreypietz/SIID_Plugin/blob/625bcb359eb2e0768341734a041e31c18e284101/HSPI_SAMPLE_CS/hspi.cs#L1135

Very interested to know your thoughts.

alexdresko commented 7 years ago

Upon closer inspection, most of the original VB.NET examples from HS don't do anything with the Condition property. Only the HSPI_SAMPLE does anything with the Condition property, and it looks almost exactly like the code from that last link I pasted.

Look at HSPI.vb here.. (from https://forums.homeseer.com/showthread.php?t=160064)

All of that nastiness needs to be abstracted away so developers don't have to worry about it.

sirmeili commented 7 years ago

I guess that was my assumption (that it was abstracted from the developers).

I think I get what you're saying. So much of stuff I'm doing I have to ask myself "Why wasn't this done in the base plugin by Homeseer? Why do I have to do it?!"

I will look into it further. I didn't see the set_Condition and noticed that in their docs it says "Homeseer sets..." which made me thing it was taken care of for me, but I guess not :(

sirmeili commented 7 years ago

I am going to close this. You were right. I got it working by overriding the method and keeping track of which trigger was in condition mode or not.

I kind of understand why they did it this way (to give more freedom maybe?), but it sure is a hassle.

alexdresko commented 7 years ago

@sirmeili Just FYI, I'm working on adding a new base class that finally achieves the main programming goals for this project. As it stands, I think it's going to be massively easier to create HS plugins. You'll get the full power of an old skool HS plugin, but it will require much less code. And the code that it does require will be much easier to understand. Ultimate plan is to strip away everything that makes HS development confusing.

sirmeili commented 7 years ago

I am doing similar with one of my plugins. I'm creating a DLL that all my plugins will share that take the bulk of PITA stuff that HS requires and generalizes it so I only need to add what I need to add for a plugin to work. If you want we can discuss it, but since I"m just now getting into c# programming, I'm not sure my ideas are sound. I have 15 years of Application development, but it is mainly web application development (mainly ColdFusion), so I'm still dealing with figuring out the differences.

alexdresko commented 7 years ago

Ain't nothing easy about the HS's plugin API. I'm basically taking my best guess, and I'll fix where it doesn't work.

You can get a sense as to where I'm going with this by looking at:

https://github.com/alexdresko/HSPI/tree/HspiBase3_stab/HSPI/HspiPlugin3 (most of HspiBase3)
https://github.com/alexdresko/HSPI/tree/HspiBase3_stab/Templates/HSPIPluginC.Dev (initial implementation of HspiBase3)

There's some good code in there, but, realistically, it's probably only about 50% complete. I don't plan on changing how the HTML is generated yet. Really just working on the main plugin architecture. HspiBase3 already takes away a lot of the guesswork, but I don't yet fully understand the relationship between actions and triggers, sub actions, sub triggers... and it seems like maybe actions and triggers are the same thing? I dunno. Going to start small and debug my way through a couple experiments until it makes sense.

sirmeili commented 7 years ago

I was looking it over quickly and I have 1 small suggestion. Don't depend on the action or trigger UID property (from strTrigActInfo). When you copy an event, all the UIDs are copied for each trigger and action. I started taking a blend of the evRef and UID to build a unique value (all UIDs in any given event are unique).

But so far I like what you've done :)

alexdresko commented 7 years ago

Keen eye there. I definitely do not know what to do in ActionFromTriggerActionInfo and TriggerFromTriggerActionInfo. That's one of those things I was just going to experiment with until it made sense. Your comment is super helpful though.

I'm so n00b, I don't even understand how/when/why triggers/actions are created. The VB sample provided by HS is certifiably useless and I can't find any documentation that explains those concepts at a high level.

alexdresko commented 7 years ago

Just pushed another round of changes to that branch. Most of today's code surrounds event registration and consumption. It's not done, but I think it's going to be pretty nice compared to what developers have to do otherwise.

sirmeili commented 7 years ago

So yeah, I'll have to share with you how I'm doing it. I've basically set up a base trigger object and each "Trigger" ends up being it's own object with it's own set of methods for handling display. In the main plugin file you then just have to to use the TANumber to pull the right trigger from the List. The list is populated in InitIO. Also, each trigger itself defines it's sub triggers so that you aren't handling that in the main plugin. The main code (Which would lie in what is basically your HSPIBase2) handles all that for you. I no longer have to worry about keepign track of TANumber or subTANumbers either. I just write the trigger object for the trigger, add it in InitIO and I'm off.

I also plan to do the same thing for Actions.

For Events, I also just completed the consumption and registration. I currently allow each trigger to consume it, but at the same time, you will be able to also handle them outside of the HSEvent method as long as you remember to call the base method as well.

I'll have to find a way to share some of my code with you so you can tell me what you think.

alexdresko commented 7 years ago

Good stuff, man. Thanks for the tips! I'm writing code by the seat of my pants right now and I won't really know if it works until I create an instance of this thing and fire it up in the debugger. With your help, I'll at least know what to prepare for.

If you're not using a source control system, consider github or https://www.visualstudio.com/team-services/. The latter allows you to create private git repos which you could share with me if you don't want your code public.

You could also email it to me@[myname].com. Or upload it to this issue as an attachment. Or create a gist (https://gist.github.com/). Or....

sirmeili commented 7 years ago

I use visualstudio.com for my git (I work off a couple different laptops at my house). I'm also flying by the seat of my pants, but I'm doing most of this while writing a plugin so I instantly see what does and doesn't work :) I've flip flopped on a bunch of stuff, but I think I've settled on something that at least seems to work for me so far. I'll get some sample code together. I'm on a deployment for work tonight, so it won't be today...LOL

alexdresko / HSPI