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.
Announcement
Collapse
No announcement yet.
When cant I inform my users that HS3 plugins won't work with HS4?
Collapse
X
-
Originally posted by rjh View PostOur 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.
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?
Comment
-
Originally posted by rjh View PostYou 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.
Comment
-
Originally posted by simplextech View Post
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!
The whole functionality of my AKSmartDevice plugin is in the Config:
Comment
-
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?
- Likes 1
Comment
-
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.
Comment
-
Originally posted by spud View Postguys, 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.
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
Comment
-
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!
- Likes 1
Comment
-
Originally posted by dcorsus View PostI 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.
Code:/// <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 ) ); }
Comment
-
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.
Comment
-
Originally posted by rjh View PostJust 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.HS4Pro on a Raspberry Pi4
54 Z-Wave Nodes / 21 Zigbee Devices / 108 Events / 767 Devices
Plugins: Z-Wave / Zigbee Plus / EasyTrigger / AK Weather / OMNI
HSTouch Clients: 1 Android
Comment
-
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.
Originally posted by rmasonjr View Post
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?
- Likes 1
Comment
Comment