HS4 Alpha Plugin Development Release

[dcorsus]

Note that we dropped support for multi instance plugins as this was just a shortcut for developers. We suggest you just add support for multiple interfaces in your plugin.We can offer ideas if you like.

Thanks for the info Rich. Just so I'm clear, multiple instances is currently supported, correct? I'm on the road so I haven't had the chance to fire up my PIs at home, apart from firing them up on my laptop and see how they initialize (they don't :-().

Are you planning to drop this at some point or you don't plan to provide PI samples that have multiple instances support?

I didn't know this was a shortcut for developers, is your recommendation we start unwinding all this dedicated code we created to shoehorn our HS3 based implementation in the singleexemultipleinstance framework you guys created?

Thanks for clarifying.

Dirk

[dcorsus]

Is anyone seeing something similar??

My PI seems to be getting a working environment different from the HS4 environment. I installed HS4 in the C:\Program Files (x86)\HomeSeer HS4 subdirectory but when the PI calls .net (Environment.CurrentDirectory) to get the current directory, it retrieves C:\Windows\System 32.

Anyone using this or seeing this? I checked the working directory for the HS4 app but that seems to be correct. Is HS4 kicking off the PIs with a specific (and wrong) working directory?

Thanks,

Dirk

[mrhappy]

Click on the name of the device on the devices page, it is a link that brings you to the device config. You will not see hs3 device config info there at this time, just the hs4 formatted page, if you create one.

The biggest reason to convert your plugins to HS4 is the new bootstrap based UI where your plugin will display properly on mobile devices. While we are trying to display the old hs3 content where possible (like for triggers/actions), there may be some real issues getting that working with every older UI element. Right now we are not displaying the H3 tab in the device properties.

HS4 will be evolving as we go forward so I strongly suggest you update your plugins as the user experience will be poor if you only offer an HS3 version.

Note that we dropped support for multi instance plugins as this was just a shortcut for developers. We suggest you just add support for multiple interfaces in your plugin.We can offer ideas if you like.

We will get the SDK docs posted shortly.

The HS4 UI is still being worked on so we understand that some features are missing or not wokring. There should be enough there to develop a plugin. New builds will be posted as functionality is added/fixed.

Am I correct in the belief (having viewed the HS4 sample and seeing the different trigger/action architecture) that even if a HS3 plugin works on HS4 that users will be starting their HS4 installations from nothing (ie no events/devices)? I can't quite see how the databases would be able to migrate (as I was storing trigger/action data inside the HS DB in HS3) but might be missing something.

[w.vuyk]

I have now aquired the license with my gmail account as I want to proceed. I am hoping macromark you can combine both accounts into one, so i will have my licenses in one account? Really do not like using google mail.

I have tried to install my plugin, but have several issues with it. It will not work with the current interface or at least random, probably depsnding on it being a sensor or a plug or a light.
A first list:

• Devices are not showing all values of subdevices, only an iconlist. For a one view per (fysical) device it may be necessary to enable viewing at least certain values. Configurable by the plugin or user might be a good idea?
• I also suspect on certain devices that values are not shown when the decimal is a comma.
• For some (type?) of devices the icon of the root device is used, others are showing the icon of a sub device. As multisesnsors tend to have several child devices, how does one determine which device's icon gets displayed as large? Please check the image for this, a simply set of devices, sensor, plug and bulb. Check the icon used?
• The controls displayed also differ per devices, chack the amse image for this. A plug can be controllen with on/off. A bulb is not showing the on/off buttons (and others) although Control Use is set for these controls. Also, for the bulbs, pressing controls does not bring any control, so there is absolutely not control possible at this stage.
• The JowiHue tabs are not shown in the device details anymore.
• Trying to create an evnet will not succeed. I can select a device in a coondition, but that selection is not visiable when the list box closes. Samegoes for actions.
• If I go to the plugins configuration page (or any other page) the only way out is back to the 'old' HS3 HTML interface - only using the back button in the browser can bring me back to the new inteface.

Am sure lots of these issues are caused by this being an alpha version and will be solved. There are a lot of challenges waiting!

Wim

[macromark]

I have now aquired the license with my gmail account as I want to proceed. I am hoping macromark you can combine both accounts into one, so i will have my licenses in one account? Really do not like using google mail.

Done - all you licenses are linked to your Gmail account now.

[w.vuyk]

Thanks Mark!

[rjh]

We tried that but there is no way to give an exe a path that goes UP a level using the EXE config file. You might notice in the HS4.exe.config we give explicit paths to important DLL files. We also now require all plugins to put there HTML files in a directory named using the ID of your plugin. We also moved many dll's files out of the HS root folder to clean up the root folder. Plugins are not allowed to save anything to the root folder. So now you have plugin files in only 3 locations:

bin/plugin_id
html/plugin_id
EXE in root folder

We would love to have plugins stored in their own isolated folder, still looking at this.

Some more suggestions for you.



Please give the plugins a proper subfolder instead of placing them in the root of the homeseer installation. As it is now, if we wanted to dockerize/containerize the homeseer app we cannot map the plugins outside the container so we must map the entire homeseer installation for persistent storage. I would love to see anything that needs to be persistent able to have it's own location.

[rjh]

Wim, don't bother too much with the new devices view just yet, its not complete. It really only supports on/off/dim and color devices at this time. Not all device controls are coded yet (don't have a plugin supporting them so far, so hard to fully test). We are modifying the sample plugin so it creates devices that support all control types.

Note that we have change device control from HS3, use the same control pairs are before. The SDK has helper functions though that make it easier to do this.

We did modify the status graphics and added a label property so you can create a graphic for specific values as well as a display label. Before the graphics status and display status were separated between the status pairs and graphics pairs. More on this will be in the docs.

Note the entire HS3 interface is still there and will work with any HS4 devices you create (go to /deviceutility), so you can test there if the device is not displaying in the new UI.

I have now aquired the license with my gmail account as I want to proceed. I am hoping macromark you can combine both accounts into one, so i will have my licenses in one account? Really do not like using google mail.

I have tried to install my plugin, but have several issues with it. It will not work with the current interface or at least random, probably depsnding on it being a sensor or a plug or a light.
A first list:

• Devices are not showing all values of subdevices, only an iconlist. For a one view per (fysical) device it may be necessary to enable viewing at least certain values. Configurable by the plugin or user might be a good idea?
• I also suspect on certain devices that values are not shown when the decimal is a comma.
• For some (type?) of devices the icon of the root device is used, others are showing the icon of a sub device. As multisesnsors tend to have several child devices, how does one determine which device's icon gets displayed as large? Please check the image for this, a simply set of devices, sensor, plug and bulb. Check the icon used?
• The controls displayed also differ per devices, chack the amse image for this. A plug can be controllen with on/off. A bulb is not showing the on/off buttons (and others) although Control Use is set for these controls. Also, for the bulbs, pressing controls does not bring any control, so there is absolutely not control possible at this stage.
• The JowiHue tabs are not shown in the device details anymore.
• Trying to create an evnet will not succeed. I can select a device in a coondition, but that selection is not visiable when the list box closes. Samegoes for actions.
• If I go to the plugins configuration page (or any other page) the only way out is back to the 'old' HS3 HTML interface - only using the back button in the browser can bring me back to the new inteface.

Am sure lots of these issues are caused by this being an alpha version and will be solved. There are a lot of challenges waiting!

Wim

[rjh]

The entire HS3 API is still there, the HS4 SDK simply wraps a new API over it. So your HS3 plugins will work the same in HS4 as they did in HS3. We have hidden many HS3 API's that we felt were either not used by anyone (hard to tell on this!), or maybe just did not work properly. But they are still there. As plugins get developed we will note any API's that are missing that you might need and see if it's worth adding them to the new HS4 API.

Am I correct in the belief (having viewed the HS4 sample and seeing the different trigger/action architecture) that even if a HS3 plugin works on HS4 that users will be starting their HS4 installations from nothing (ie no events/devices)? I can't quite see how the databases would be able to migrate (as I was storing trigger/action data inside the HS DB in HS3) but might be missing something.

[rjh]

Multiple instances and multiple instance EXE is not supported (note that the HS3 support is still there for an HS3 plugin). It really is a mess in HS to support this and we felt it would be easier for the plugin to support multiple instances. If our thinking is wrong, let me know why.

All we were doing was creating the HSPI interface more than once and giving each instance a name. This can easily be done in the plugin.

The user interface in HS3 was confusing at best when trying to support multiple instances. It would be better for users if you just had a settings page where the user could add or remove your hardware devices. In your case, sonos hardware.

Thanks for the info Rich. Just so I'm clear, multiple instances is currently supported, correct? I'm on the road so I haven't had the chance to fire up my PIs at home, apart from firing them up on my laptop and see how they initialize (they don't :-().

Are you planning to drop this at some point or you don't plan to provide PI samples that have multiple instances support?

I didn't know this was a shortcut for developers, is your recommendation we start unwinding all this dedicated code we created to shoehorn our HS3 based implementation in the singleexemultipleinstance framework you guys created?

Thanks for clarifying.

Dirk

[dcorsus]

Multiple instances and multiple instance EXE is not supported (note that the HS3 support is still there for an HS3 plugin). It really is a mess in HS to support this and we felt it would be easier for the plugin to support multiple instances. If our thinking is wrong, let me know why.

All we were doing was creating the HSPI interface more than once and giving each instance a name. This can easily be done in the plugin.

The user interface in HS3 was confusing at best when trying to support multiple instances. It would be better for users if you just had a settings page where the user could add or remove your hardware devices. In your case, sonos hardware.

Not sure the multiple instances was the biggest task, all the calls adding the instance name, the webpage with jquery objects now need changing, so not a few changes.

I’m probably dense but if the HS3 PIs are supported and running under HS4, then why change anything, what am I missing?

Should I assume the mediaapi is history as well?

[rjh]

Odd, plugins are started with the same code as HS3, so I don't believe there is any change there. I will check when I get a chance.

Is anyone seeing something similar??

My PI seems to be getting a working environment different from the HS4 environment. I installed HS4 in the C:\Program Files (x86)\HomeSeer HS4 subdirectory but when the PI calls .net (Environment.CurrentDirectory) to get the current directory, it retrieves C:\Windows\System 32.

Anyone using this or seeing this? I checked the working directory for the HS4 app but that seems to be correct. Is HS4 kicking off the PIs with a specific (and wrong) working directory?

Thanks,

Dirk

[rjh]

I am not saying that a conversion is easy, we just felt that going forward it doesn't make sense. The old UI managed the instances and the new UI does not. So we would have to modify the new UI. We felt that the user experience with this was not good, hence the reason for the change.

When I say that HS3 plugins are supported under HS4, they work, but they are managed with the old UI, so not optimal for the user.

In regards to the MediaAPI, I believe we talked about this with others a while back and decided that devices would be used for control, rather than an API. So no work has been done to that API and we have left it out of HS4 (what was there, is still there for HS3 plugins).

If devices won't work, let me know the issues.

Not sure the multiple instances was the biggest task, all the calls adding the instance name, the webpage with jquery objects now need changing, so not a few changes.

I’m probably dense but if the HS3 PIs are supported and running under HS4, then why change anything, what am I missing?

Should I assume the mediaapi is history as well?

[happnatious1]

In regards to the MediaAPI, I believe we talked about this with others a while back and decided that devices would be used for control, rather than an API. So no work has been done to that API and we have left it out of HS4 (what was there, is still there for HS3 plugins).

If devices won't work, let me know the issues.

No reason to believe, it's a fact, you and spud worked on it together and the API was never heard from again.

[dcorsus]

No reason to believe, it's a fact, you and spud worked on it together and the API was never heard from again.

Actually what some of us were asking for was an "enhanced" listbox "device". A device that could be dropped on an HST screen but content could be populated dynamically by a PI, irrespective whether the content represents music tracks, or email titles, or do-to action items. So no shoe-horning of a navigation flow from artist, to album to tracks or whatever was baked into the MediaAPI. I believe there was a listbox you could drop onto an HST screen, it was very rudimentary and linked to an HS device, nothing dynamic and it required changes. PCP actually wrote a very clear spec for it but also that didn't go anywhere. Actually the jqListBoxEx functions that was made available to drop onto our own GUI config screens, was perfect for me. The webpage I provided through the PI had 2 of these, one showing a navigation tree, where you could navigate in or out of any type of linked content, whereas the other one was used to show a queue of selected items. Unfortunately, the only way to get that into HST screens was through iFrames and a lot of in-depth HTML knowledge. As far as I can tell, only one or two experts attempted to embedded it into their HST control screens.

Am I correct to assume that the new GUI I now see, is going to be the same for mobile devices (or HST enabled devices)? Is HST over time going to wither away on the vine?

All I need is a "dynamic" listbox that queries the PI directly instead of retrieving info from the HS Database and events (click, double click, selection, load....) are conveyed to the PI allowing the PI to update the content and we come full circle with HS updating the listbox on the attached control devices.

Dirk