Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Webinar Topic Request thread
#11
Images are an issue due to copyright, and we don't have the resources to police such things. And we don't really have any good tool to share things, so something external would probably be appropriate. Maybe some sort of Github type thing could work.

What really isn't being taken advantage of is the ability to create reusable content via V2 compliance. Given the consistency of interface that V2 compliant drivers have, it should be possible to create more reusable stuff that is reusable in a very direct way, with minimal fiddling. So you could make volume control, input switcher, thermostat, color lighting, etc... small chunks of interface that would work with any device that implemented the right device class. Just use as is or copy and paste the widgets and search and replace the moniker.

The problem of course is look and feel. If you are doing these things for yourself, or you are a pro who is doing many installs using the same basic building blocks, then you'd have everything looking the same. Otherwise, the person who gets the stuff will either end up with a Frankenstein system, or will have to update the look to fit his own stuff, which may or may not be within his abilities or tolerances.

Of course a collection of such things created specifically for sharing and re-use could come up with a common look and feel and all of them try to match that I guess.
Dean Roddey
Software Geek Extraordinaire
Reply
#12
(01-06-2018, 02:02 AM)znelbok Wrote: There is a way that I saw something similar being done with overlays and thus removing the need to change all the actions on the widgets - That was a long time ago and I would need to investigate that logic again.  It would be a better way again to do this

Definitely you can use the loading of an overlay to simplify reuse of the same stuff for multiple devices of the same type. You can also just have a button or list of the devices and select one and directly apply the changes there.

There are basically two issues:

1. You do LinkToField commands on those widgets that reference fields
2. You store something about the selected device in a global variable or popup value or some such, and you use this in the actions that reference that device.

So #1 handles reading the fields and #2 handles writing the fields. Using this you can create, say, a thermostat handler that you can easily reuse with multiple thermostats on the fly by just letting the user select which one he wants to control.
Dean Roddey
Software Geek Extraordinaire
Reply
#13
I would like to see demonstrative webinars. Each person takes a turn 'hosting' where they demo their interfaces and setup, showing us their designs, backend logic, and briefly explaining why they did what they did (like IVB's webinar last night was to avoid having to use Admin Console frequently).

It would be great to see what others are doing, and recording it could offer a reference point of sorts.
do the needful ...
Hue | Sonos | Harmony | Elk M1G // Netatmo / Brultech
Reply
#14
(01-06-2018, 09:54 AM)Dean Roddey Wrote: What really isn't being taken advantage of is the ability to create reusable content via V2 compliance. Given the consistency of interface that V2 compliant drivers have, it should be possible to create more reusable stuff that is reusable in a very direct way, with minimal fiddling. So you could make volume control, input switcher, thermostat, color lighting, etc... small chunks of interface that would work with any device that implemented the right device class. Just use as is or copy and paste the widgets and search and replace the moniker.
Not sure how exactly what you mean by "create reusable content", or how to do it. Keep in mind you know everything about everything here, we just use it occasionally. All I know is I create a driver, use photoshop to create buttons, import images into CQC, and build templates. Zero idea what to do differently.

Last time we tried exchanging templates the big issue was the name of the drivers varying from person to person, and loading someone else's would result in nulling out the action when you opened it up in the action editor. Is that still true?
------------------------------------
Devices I'm phasing out: ISY, NuVo
My vlogs: https://www.youtube.com/c/IVBsHomeAutomation
Reply
#15
Because V2 drivers provide a consistent interface, it's possible to create templates (either to be used as is or just to have the contents stolen and embedded in something else) that can work against any other device that implements the V2 device classes used by that template. Same for global actions or CML macros.

So, for instance, any device that supports volume control (volume, mute, volume adjust) uses the Audio device class, and it exposes the exact same fields to do that. That means you can create say, a volume control template which consists of a set of cooperating widgets, which targets this set of fields. The only difference is the driver name, and sometimes the sub-unit name. So you can paste those widgets into your own template, search and replace them to get the moniker right, and it should work correctly.

That wasn't possible before because every driver could implement different fields to do volume control, or any other type of functionality. We have a whole set of device classes that various V2 drivers implement, and they can be used similarly. I can give a working example later. The auto-gen templates have a generic volume control popup that will work with any device that implements the Audio device class, for instance. So it's used as is anywhere that I need to do volume control in the auto-generated templates.

The reason commands get nulled out isn't because of different driver monikers, but because of missing widgets. If the target widget (the one an action command acts on) isn't present, the command cannot be verified or understood. So that's a different thing. So generic template content, where widgets send commands to each other, has to be 'self contained' if you want someone else to be able to paste that batch of widgets into their own template and not have missing command targets.
Dean Roddey
Software Geek Extraordinaire
Reply
#16
OK you'd know better, but I really thought commands got nulled out because we didn't have drivers named the same way as the templates we were importing. That's why my drivers were named "sample-variables-driver" and "sample-concerto"
------------------------------------
Devices I'm phasing out: ISY, NuVo
My vlogs: https://www.youtube.com/c/IVBsHomeAutomation
Reply
#17
Nope. That would just make a field read/write fail when it was finally invoked, if the driver name wasn't updated before then. The only think that comments out the commands is if the target is not found.

Of course when you do a template import it will try to find devices of the same make/model and let you substitute those. It will ask during the import and do the search and replace for you. If you only have one of the same type it will automatically pick that one, else it'll let you select one. Unfortunately it has to be the same device, not just any V2 device, because we don't know what aspects of that driver are used in the template being imported.
Dean Roddey
Software Geek Extraordinaire
Reply
#18
(01-06-2018, 03:18 PM)Dean Roddey Wrote: Unfortunately it has to be the same device, not just any V2 device, because we don't know what aspects of that driver are used in the template being imported.

So if I have an ISY with all my widgets setup, if I send someone else my templates and they do NOT have an ISY, will the actions be nulled out after importing when they open my template? If so then this is still not actually real world useful, as they can't load my templates in, see how they work, then change actions to suit for them. They'd have to create "dummy" drivers first with pretend-versions of the ISY that are in "wait for connect" mode, and every other driver referenced in my template. Which is doable, but i have to include a listing of every dummy driver they need to create before importing mine (and hopefully they don't trip over their tier limits).
------------------------------------
Devices I'm phasing out: ISY, NuVo
My vlogs: https://www.youtube.com/c/IVBsHomeAutomation
Reply
#19
No, it won't do anything to the action commands. It will just mean that the logic in the templates will fail with field read/write errors until they deal with the device/field names. The only thing that comments out action commands is if the target of the action command isn't present. The only ones that are optional are widgets. As long as the template you give the person is self-consistent internally, that shouldn't happen.

If you give the user a template and he grabs individual widgets out of it, and those are set up to send commands to other widgets that only exist in the template it grabbed it from, then yes, it will comment out those commands. You can only copy over self-contained sets of widgets if you want to avoid that, i.e. a set of widgets that only refer to each other.


As far as the devices/fields, the V2 architecture only defines the form of the fields, it doesn't of course require you name everything in the Kitchen or Living room a certain way. So it means any given dimmer or thermo or whatever has the same form of fields. It doesn't mean that everyone's dimmers are named the same.

So, in the V2 world, for instance, turning a light off or on involves a field named:

LGHT#Sw_xxxx

where xxx is the name you give to the light. So you have to update the light names, but they are always consistently named, so you can reasonably do search and replaces to update them.

Where it works out better is in things like thermos, volume control, media repos, media renders, and other things where there is a good bit more functionality associated with the particular device class. So, with a thermostat, it's similar to the above. All the thermostat fields have a consistent format, like:

THERM#xxx~CurrentTemp
THERM#xxx~LowSetPoint

and so forth, where xxx is the name you gave to the thermostat. So it's fairly straightforward to select the widgets and search and replace THERM#Bubba~ with THERM#Jane~. That's all it requires.

If you don't have a lot of individual things, you can use the new dynamic content creation stuff, which the overlay now supports. It's sort of like auto-gen on the fly. It has some limitations, but you can give it 'template template', i.e. a template that is set up for a single whatever, e.g. thermostat, then either a field or a device name, and a list of replacement fields or device names.

It will repeatedly take that template template, updated it based on each of the replacement names, and spit out the templates in a left to right sequence. That leaves you with a scrollable overlay of thermostats where you never actually committed to any names. Each time you load the template, it generates those widgets for you. If you add another thermostat, just add it to the replacement list.

Of course that involves overhead. If you have 250 lights, that's not practical for the IV to spit that out every time you load the containing template. But, of course each room could have its own list and load those. Even if you created the list manually a 250 light scrollable template wouldn't be very practical anyway. For a lot of things, there are only a handful or ten or whatever and it's completely reasonable to generate that output on the fly as long as the template template is not really complex.

Something I'd like to do but haven't had the chance, is to let you indicate a number of rows, and it will then generate rows number of rows with x/rows copies per row. Then you can scroll it in both directions to find the thing you want.

Here is a video that demonstrates dynamic generation. This is NOT auto-gen, this is just an automatic search and replace and replication of a source template. It doesn't require V2 drivers to work. But, the point of the above is that, if you do use V2 drivers, then this scheme can make it pretty easy to create generic templates that don't depend on the 'what did I name my lights, thermos, etc...' problem.

https://www.youtube.com/watch?v=BJGzpDRe904
Dean Roddey
Software Geek Extraordinaire
Reply
#20
(01-06-2018, 09:54 AM)Dean Roddey Wrote: What really isn't being taken advantage of is the ability to create reusable content via V2 compliance. Given the consistency of interface that V2 compliant drivers have, it should be possible to create more reusable stuff that is reusable in a very direct way, with minimal fiddling.  So you could make volume control, input switcher, thermostat, color lighting, etc... small chunks of interface that would work with any device that implemented the right device class. Just use as is or copy and paste the widgets and search and replace the moniker.

This brings on the issue on availability of V2 driver...
You were understandably busy with v5 and follow-on releases, and the updates to drivers stalled.
Most of my devices are also EOL, so unlikely you will have a big appetite to develop a V2 driver.
And than there are the non-released drivers...

Any chance you rethink the autogeneration concept to work with pre-specified set of drivers/fields, in other words pick the light fields, security fields, audio fields for a room and generate the interface with semantics for light, motion, audio etc.
Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  Scheduling next webinar (Sonos/TTS) IVB 6 1,841 02-04-2018, 10:51 PM
Last Post: IVB
  CQC Webinar Fri 1/5, 5pm PST/8pm PST IVB 3 1,218 01-05-2018, 10:27 PM
Last Post: IVB
  Redditors: Monthly HA Poll / usage thread IVB 0 603 09-07-2016, 10:31 AM
Last Post: IVB
  your online webinar sw of choice IVB 5 1,107 01-07-2016, 10:46 AM
Last Post: IVB
  Official CEDIA Talk Thread Dean Roddey 5 1,561 09-13-2009, 03:23 PM
Last Post: IVB
  Official Name the Remote Viewer Thread Dean Roddey 69 7,404 04-28-2009, 03:17 PM
Last Post: Steve
  Water Tank level - by request znelbok 11 1,827 05-07-2008, 01:56 AM
Last Post: znelbok
  noshali 220v thread noshali 31 5,094 02-06-2007, 03:35 PM
Last Post: rhamer
  myHomeCookingPC.com (recipe mgmt system) thread IVB 74 6,885 01-29-2007, 09:53 PM
Last Post: IVB
  Comment on Driver request znelbok 14 2,708 01-29-2007, 12:36 PM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)