When cant I inform my users that HS3 plugins won't work with HS4?

[rjh]

Our plan is to make sure all hs3 plugins run in HS4. If yours is not working we will have a look and fix the UI. Please give us a little more time to test. When I find an hS3 plugin that we cannot make work I will let you know. For now you can assume they will work. Working on mobile is the only real issue, but we will explain the issues there.

[simplextech]

Our plan is to make sure all hs3 plugins run in HS4. If yours is not working we will have a look and fix the UI. Please give us a little more time to test. When I find an hS3 plugin that we cannot make work I will let you know. For now you can assume they will work. Working on mobile is the only real issue, but we will explain the issues there.

Then please tell me what I'm supposed to say to my users when they ask about HS4? As of today my plugins do not work or are unusable. Until the documentation is usable, clean good samples are available and a porting guide/path for plugins has been provided I'm not spending time on trying to upgrade plugins without a target.

What about the license system? Lots of time will be spent to make plugins be usable even passable in HS4 and all of that for free?

[rjh]

You can offer an upgrade to an existing license. Do you need more info? I should have the upgrade screen coded in a few days.

I will look at your life360 plugin and see what the issue is.

[simplextech]

You can offer an upgrade to an existing license. Do you need more info? I should have the upgrade screen coded in a few days.

I will look at your life360 plugin and see what the issue is.

that plugin and AmbientWeather are mostly status devices and they don't "fit" with the HS4 UI needing to have a root for each "feature" to display.

[alexbk66]

jseer rjh OH is this what you mean by "take care of it"?????

https://forums.homeseer.com/forum/in...78#post1328878

So now Rich you've gone out and boldly proclaimed that HS3 plugins are supported in HS4... yeah BUT THEY DON'T WORK with the new UI therefore they DO NOT WORK with HS4 they work with HS3 UI which is NOT HS4 because HS4 is ONLY THE UI and changes made to SUPPORT THE UI.....

sirmeili , alexbk66, Blade bpwwer Shodan Anyone have a HS3 plugin that WORKS with HS4 without any re-coding???? NONE OF MINE JUST WORK like the magic being sold!

No, my plugins don't work and need to be refactored. And it's a lot of work. In my plugins I have a lot of code in the Config pages - and that's the main HS4 change!

The whole functionality of my AKSmartDevice plugin is in the Config:

[alexbk66]

And somebody asked already - but was ignored - how do we handle in HS4 the sutuation when single device (i.e. relay module) controls lights (for example) in different rooms?

RaspberryIO "device" supports 27 IO - how you gonna display this in HS4? I hope Spud will be able to sort it out?

[spud]

guys, do not forget that the new UI is still work in progress, yes there is still some bugs and some missing features in HS4, but once those bugs are fixed I'm confident that all my HS3 plugins will work in HS4 without any recoding.

For example here is a some screenshots of my HS3 EnvisaLink plugin in HS4 (I didn't make any change to the code):

Tile View:


Grid View:


Currently the Tile view only shows one status (the partition status on my screenshot), but JLDubz is already working on that so that a tile can show more than one status.
If you don't like the tile view, you can use the grid view where all status and controls are showing (You can see that on my second screenshot the partition status is missing, but this is just a bug)
As for the config page, it shows exactly as in HS3.

So it seems to me that we are not far from a very usable plugin without any recoding on the plugin side.

[dcorsus]

guys, do not forget that the new UI is still work in progress, yes there is still some bugs and some missing features in HS4, but once those bugs are fixed I'm confident that all my HS3 plugins will work in HS4 without any recoding.

For example here is a some screenshots of my HS3 EnvisaLink plugin in HS4 (I didn't make any change to the code):

Tile View:


Grid View:


Currently the Tile view only shows one status (the partition status on my screenshot), but JLDubz is already working on that so that a tile can show more than one status.
If you don't like the tile view, you can use the grid view where all status and controls are showing (You can see that on my second screenshot the partition status is missing, but this is just a bug)
As for the config page, it shows exactly as in HS3.

So it seems to me that we are not far from a very usable plugin without any recoding on the plugin side.

I agree with Spud, initially I was to run for the hills as well but most is working and what isn't I raised a bug/issue and I'm confident will be solved. I have to admit, Alex's config screens look mighty awesome and I can understand that the effort he has spent making it amazing might be a step down when shoehorned into more generic controls that tend to work OK on all devices as opposed to looking and working great. It is my view that we should break the big problems we have into bite size and manageable pieces and it would be great if the HS team could get something like bugzilla up and running again. I learned today that issues raised on github are only against the SDK and I think a lot more is going to come out of the testing that has little to do with the SDK and all with the new UI functions and layout. Putting them here in the forum, I don't think is that great and I think a lot will be lost, there will be no visibility into what is happening and more frustration will surface.

In support of some of the frustration here on the forum, I would recommend for future HS4.x/HS5 releases, the HS team establishes and maintains a regular developer conference/forum to listen to us. I applaud them for publishing a roadmap of sorts but I think regular real-time interaction with developers would make an even better future. I started out with a >1000 errors when I ported my code into the "HS4 framework" and whilst I grinded through most of these issues, I still have ways to go to recreate the config and control screens, but the PI is running as it should. A lot of the errors were just syntax changes and each time I go through this pain (same for HS2->HS3) I'm being reminded to abstract the functions towards the HS interface more, put them in common routines and have to prevent massive refactoring of the code to get to the same point. Unfortunately, most of these errors, I had to go fix, because the HS team had the objective to make the PI development easier so more developers can chime in. I had to admit, to me, the complexity all came from creating config screens, devices and events and that part seems to be exactly the same complex. The minimum set of must have methods for a base line Pi was reduced but that part was (in my opinion) easy as heck.

Here you have it, my $0.02

Dirk

[alexbk66]

From my SW development experience (30 years) the new significant release takes 6 mo to 1 year. The error HST made - informing the developers about the new release a month before the release.

The common SW engineering mistake - rush the development just a month before - then the whole process is squashed and lots of mess is produced.

And especially in our case - since it's not our main full time job - the time frames should be more flexible and probably the developers (us) should be more involved in planning process.

Not like HST did it - here's the plan and you must follow it!

[alexbk66]

I had to admit, to me, the complexity all came from creating config screens, devices and events and that part seems to be exactly the same complex. The minimum set of must have methods for a base line Pi was reduced but that part was (in my opinion) easy as heck.

With the libraries I created - the config screens didn't take much of work, i.e. the example code for the screenshot above:

/// <summary>
/// Generate HTML for Triggerd Tab
/// </summary>
/// <param name="stb"></param>
private void BuildTabTriggers(StringBuilder stb)
{
    // 0. This device info
    BuildTable_DeviceInfo(stb);

    if (!String.IsNullOrEmpty(ctrl_states))
    {
        // Read from PED only when Trigger Tab is shown
        // TEMP - TODO: Actually, device itself needs triggerGroups for functioning!
        device.triggerGroups.LoadGroups();

        // If no groups yet - make empty group
        if (device.triggerGroups.Count == 0)
            device.triggerGroups[1] = new TriggerGroup(1, device);

        // Sort by display order
        List<TriggerGroup> groups = device.triggerGroups.Values.ToList();
        groups.Sort((x, y) => x.order.CompareTo(y.order));

        foreach (TriggerGroup group in groups)
        {
            BiuldTriggerGroup(stb, group);
        }
    }
}

/// <summary>
/// Biuld TriggerGroup table
/// </summary>
/// <param name="stb"></param>
/// <param name="group"></param>
private void BiuldTriggerGroup(StringBuilder stb, TriggerGroup group)
{
    string[] hdr =
    {
        AddBtn(group.MakeIdStr("adddev"), "Add device to trigger group", small: true),
        "",
        LocationLabels.Item1,
        LocationLabels.Item2,
        "Device",
        "Trigger State"
    };

    TableBuilder table = new TableBuilder( GroupTitle(group),
                                            ncols: hdr.Length,
                                            tableID: group.MakeIdStr("table_group"),
                                            page_name: PageName
                                            );
    // Edit Name/Description
    BuildGroupEdit(table, group);

    // Row for group options
    BuildGroupOptions(table, group, in_table: false);

    table.AddBlankRow();
    table.AddRowHeader(hdr);

    // Add rows for devices in group.groupSettings.deviceIDs
    for (int i = 0; i < group.groupSettings.deviceIDs.Count; i++)
    {
        TableBuilder.TableRow row = table.AddRow();
        BuildDeviceRow(row, i, group);
    }

    string html = table.Build( initiallyOpen: GetSlideOpen(table.tableID) || group.editMode ,
                                titleAlt: GroupTitle(group, alt: true));
    stb.Append( html );
}

/// <summary>
/// Add row for device in group.groupSettings.deviceIDs
/// </summary>
/// <param name="row"></param>
/// <param name="ind">Device index in deviceIDs list</param>
/// <param name="group"></param>
public void BuildDeviceRow(TableBuilder.TableRow row, int ind, TriggerGroup group)
{
    int devID = group.groupSettings.deviceIDs[ind];
    DeviceBase dev = ((HSPI)plugin).controller.GetDevice(devID);

    var del_btn = DeleteBtn(group.MakeIdStr("deldev", ind), "Remove device from group", value: devID.ToString(), small: true);
    row.AddCell(del_btn, attrs: " style='padding-left: 5px;' ");

    // Selector ID for btn_change_device is unique for this group/device
    // i.e. "grp_1_device_0" - update device 0 in grp 1 to selected device ID
    // exclude - devices already in group, and device itself, Except for current device id
    BuildDeviceSelector( row,
                            dev,
                            selectorID: group.MakeIdStr("setdev", ind),
                            devices: ((HSPI)plugin).controller.devices,
                            exclude: group.ExcludeList(ind));

    // Build list of Status states for trigger device
    row.AddCell(BuildVSVGPairsDropList( dev,
                                        name: group.MakeIdStr("setstate", devID),
                                        selectedValue: group.TriggerStateStr(devID), // TEMP - TODO: ADD PREFIX/SUFFIX!
                                        StatusControl: ePairStatusControl.Status,
                                        selectedPair: out MyPair selectedPair,
                                        AddBlankRow: true, // By default don't select any state
                                        AddRange: true //Add range pair in addition to split range pairs
                                        ) );
}

[rjh]

Just a note to mention that we are modifying the default HS3 style sheets so HS3 config screens will follow the look of the HS4 screens. This won't make them mobile friendly but they look more like they belong. Depending on the complexity of the pages, it might be possible to just include the bootstrap CSS and JS files and then make some tweaks to your screens. Namely replacing table tags with the bootstrap row/col classes. Then the pages will be responsive. I have not tried this yet though.

[rmasonjr]

Just a note to mention that we are modifying the default HS3 style sheets so HS3 config screens will follow the look of the HS4 screens. This won't make them mobile friendly but they look more like they belong. Depending on the complexity of the pages, it might be possible to just include the bootstrap CSS and JS files and then make some tweaks to your screens. Namely replacing table tags with the bootstrap row/col classes. Then the pages will be responsive. I have not tried this yet though.

In HS3, I spent a LOT of time using the clsPageBuilder in my plugin. Will I need to make any changes for the look/feel for HS4?

[rjh]

We are not done with the style sheet changes, but so far it looks pretty good. I might have a first pass ready for this Thursday's build so developers can see how their pages look.

In HS3, I spent a LOT of time using the clsPageBuilder in my plugin. Will I need to make any changes for the look/feel for HS4?