Author Topic: Vera Plugins - Development environment and tools needed  (Read 5599 times)

Offline Dragos Perju

  • MiOS Official
  • Global Moderator
  • Sr. Newbie
  • *****
  • Posts: 48
  • Karma: +4/-0
  • Think different
Re: Vera Plugins - Development environment and tools needed
« Reply #15 on: August 22, 2018, 04:18:24 am »
I am profoundly impressed by the level of detail that you provided as feedback. On some things you mentioned (and believe me we will take them one by one in R&D and create tickets) it sounds that backwards compatibility would brake in order to fix them the right way. @rigpapa and @akbooer you would take the time to update the plugins so they run on such a firmware (of course you would have early access so you can test and develop your modifications)?

While the first few iterations of our new UX will just add some info on top of already definition of static data so it is backwards compatible, this is where we want to go in the future and we hope that you are going to support us. We will make sure that tools and necessary hardware will be at your disposal so we can make your plugins available on the next generation of engine.

Regarding UX our strategy changed to a mobile first one.

This means that we will implement a mobile oriented interface so that not only our Vera app, but also third party apps can display consistent information in fast way.

We will let you know the inputs that we gathered from you feedback and the status as they go into development. Thank again for such a fantastic answer and don't be shy on adding more if you have.

NO! I do not want to be doing set up on a mobile device. I still want to do it with a keyboard and a mouse. Going mobile may be considered a move forward, but for speed and ease it is a move backward.

I agree!!!

We should give equal weight to both Mobile and Desktop!

When we say mobile first, we say that the web application will follow clean design and will have the same tile system as the mobile UX. We mean that features will NOT be developed on web first and then will last forever to see them in the mobile apps as well. Mobile first means fast, responsive UI with un-cluttered interface. If by setup you mean scenes, no matter if was desktop or mobile we did a poor job with the UX there. But that will change. Completely.

People use their phones a lot. Google only allows you to setup the Google Home speaker from their the mobile apps. We need to make our UX intuitive and simple so you will be pleased to setup part of your system with your phone and that interface needs to run on web as well. You are also probably thinking that setup is a one time thing once every couple of months but I believe in a more flexible automation system where you can update your scenes on the fly, just by using your voice or dragging a slider in a user interface.

So DO NOT worry, nobody is killing the web application. We are just adding what's missing on the mobile apps. Then you can choose where to do the setup.  8)
Dragos Perju,
Product Manager @ MiOS

Offline therealdb

  • Full Member
  • ***
  • Posts: 181
  • Karma: +3/-0
  • Automate all the things!
Re: Vera Plugins - Development environment and tools needed
« Reply #16 on: August 22, 2018, 08:20:52 am »
Dragos, I don't think tile based interface is the way to go.
In fact, as reported here, we want more control and the ability to customize the layout.

I'm a web developer myself and I know that responsive design is harder, but it's not impossible to design a grid system that adapts.

Take a look at adaptive card by Microsoft. A layout system like that will be a game changer and open the way to very creative plug-ins layout.
Vera Edge EU, Fibaro FGRM 222 (12), Fibaro FGS 223 (20), Fibaro FGS 222 (5), Fibaro Universal Binary Sensor (2), Fibaro Plug (3), NeoCoolCam Door Sensor (3), NeoCoolCam PIR (2), Nest (3), Home Server running my own integrations, Harmony Hub, OpenSprinkler, Personal Weather Station, Sonoff TH & more

Offline Dragos Perju

  • MiOS Official
  • Global Moderator
  • Sr. Newbie
  • *****
  • Posts: 48
  • Karma: +4/-0
  • Think different
Re: Vera Plugins - Development environment and tools needed
« Reply #17 on: August 22, 2018, 09:43:08 am »
Dragos, I don't think tile based interface is the way to go.
In fact, as reported here, we want more control and the ability to customize the layout.

I'm a web developer myself and I know that responsive design is harder, but it's not impossible to design a grid system that adapts.

Take a look at adaptive card by Microsoft. A layout system like that will be a game changer and open the way to very creative plug-ins layout.

I know about the technology but most of the users just want things to work out of the box. So for controlling, layout need to be as simple as possible. It's important to be customisable so user can put things where they want and find them where they left it. This we will fully support together with left/right swipe-able pages on the dashboard.

Regarding adaptive cards and other technologies like this (including some of our own) those are definitely on our roadmap for the advanced control panel of the tile. The one that is one tap away. This is where that technology will prove it's power and be super useful.
Dragos Perju,
Product Manager @ MiOS

Offline rstrouse

  • Hero Member
  • *****
  • Posts: 836
  • Karma: +30/-9
Re: Vera Plugins - Development environment and tools needed
« Reply #18 on: August 22, 2018, 10:29:45 am »
the tiles are a tap away from the detailed control panel of the device.
Simplifying the initial panels will definitely reduce the real estate and in turn reduce the scrolling.  Getting rid of the white-space as well as allowing important indicators on the first tile should do it all justice.  Two taps to control the advanced features is not terrible if I can get rid of the scrolling.  However, please don't boil this down so I can only show one state value from the device. 

For instance, there are two values salt level and status that indicate the health of the device.  A pump has energy level, flow and/or rpm. For pool heat there is the SetPoint, AirTemp, SolarTemp, and the WaterTemp.  I do suppose you could boil that down to SetPoint and WaterTemp as well as some indication as to which heat source might be on.  Then I could let the user fart with it on the detail panel.

What I am trying to say is that everything isn't a binary switch.  Just because the answer is not; yes or no, on or off, 0 or 1, doesn't mean the question was the wrong one.  The punch line here is please don't limit us to a single binary state per device.  Pool heat is not just on or off.  It is heating with solar, gas, heat pump or off.  And whether you have it set to come on when the conditions are right.

The approval process and the necessary steps to publish an app will change for the better.
Yeah there was even a period where the updates weren't being brought down for the current version.  Nothing better than chasing bugs you fixed only to realize the changes weren't making it to the user.  If you say it's fixed I will give it another go.

Regarding the hard codings that were made along the way, we are going to fix that. It's going to be put on R&D's table.
You may find that a huge portion of the code actually goes away when you remove all the repeated code.  Don't get me wrong I have development teams too.  I know this stuff creeps in because at the time it seemed like a good idea.  The real measure is whether you have the courage to fix it when you realize it got outta hand.
1xVera3 1.7.619, 4xLinear WT00Z, 3xLinear WS15Z, 1xLeviton VRCZ4, 10xCooper RF9540, 1xLeviton VRFI10, 1xLeviton VP00R, 2xLinear GD00Z-4, 1xGE/Jasco 45612, 1xGE/Jasco 45610,  4xGE/Jasco 45605, 2xYale YRD220-ZW-619, 1xCaddx NX584, Autelis Intellitouch Pool Control, OpenSprinkler

Offline Sammy2

  • Hero Member
  • *****
  • Posts: 870
  • Karma: +5/-5
Re: Vera Plugins - Development environment and tools needed
« Reply #19 on: August 22, 2018, 12:48:11 pm »
the tiles are a tap away from the detailed control panel of the device.
Simplifying the initial panels will definitely reduce the real estate and in turn reduce the scrolling.  Getting rid of the white-space as well as allowing important indicators on the first tile should do it all justice.  Two taps to control the advanced features is not terrible if I can get rid of the scrolling.  However, please don't boil this down so I can only show one state value from the device. 

For instance, there are two values salt level and status that indicate the health of the device.  A pump has energy level, flow and/or rpm. For pool heat there is the SetPoint, AirTemp, SolarTemp, and the WaterTemp.  I do suppose you could boil that down to SetPoint and WaterTemp as well as some indication as to which heat source might be on.  Then I could let the user fart with it on the detail panel.

What I am trying to say is that everything isn't a binary switch.  Just because the answer is not; yes or no, on or off, 0 or 1, doesn't mean the question was the wrong one.  The punch line here is please don't limit us to a single binary state per device.  Pool heat is not just on or off.  It is heating with solar, gas, heat pump or off.  And whether you have it set to come on when the conditions are right.

The approval process and the necessary steps to publish an app will change for the better.
Yeah there was even a period where the updates weren't being brought down for the current version.  Nothing better than chasing bugs you fixed only to realize the changes weren't making it to the user.  If you say it's fixed I will give it another go.

Regarding the hard codings that were made along the way, we are going to fix that. It's going to be put on R&D's table.
You may find that a huge portion of the code actually goes away when you remove all the repeated code.  Don't get me wrong I have development teams too.  I know this stuff creeps in because at the time it seemed like a good idea.  The real measure is whether you have the courage to fix it when you realize it got outta hand.

Very glad to see you chime in rstrouse!

Because of this discussion I now know why Pool Control for Jandy never made it into the store. You'd submit it and nothing would happen with it on MiOS' end.

I've repeatedly stated and have yet to hear a response from the new MiOS team but we need to have the android app work just as well as the WebGUI and iPhone app does with plugins such as your Pool Control. I've uninstalled the app and login at home.vera.com whenever I need to use the app but usually use ImperiHome instead but it doesn't recognize Macros that are in Pool Control so things get out of sync so to speak.

Offline therealdb

  • Full Member
  • ***
  • Posts: 181
  • Karma: +3/-0
  • Automate all the things!
Re: Vera Plugins - Development environment and tools needed
« Reply #20 on: August 22, 2018, 01:01:19 pm »
I know about the technology but most of the users just want things to work out of the box. So for controlling, layout need to be as simple as possible. It's important to be customisable so user can put things where they want and find them where they left it. This we will fully support together with left/right swipe-able pages on the dashboard.

Regarding adaptive cards and other technologies like this (including some of our own) those are definitely on our roadmap for the advanced control panel of the tile. The one that is one tap away. This is where that technology will prove it's power and be super useful.

I thinks it's not a problem, because this is developers stuff - end users will simply use it.
While I'm OK with tiles (I was technical lead for a lot for windows phone and Windows 8/10), they have a problem: action is always a tap away and informational are usually hidden.

I still believe you can combine both and give us more interactivity, if needed. Don't forget power users and developers.
Vera Edge EU, Fibaro FGRM 222 (12), Fibaro FGS 223 (20), Fibaro FGS 222 (5), Fibaro Universal Binary Sensor (2), Fibaro Plug (3), NeoCoolCam Door Sensor (3), NeoCoolCam PIR (2), Nest (3), Home Server running my own integrations, Harmony Hub, OpenSprinkler, Personal Weather Station, Sonoff TH & more

Offline therealdb

  • Full Member
  • ***
  • Posts: 181
  • Karma: +3/-0
  • Automate all the things!
Re: Vera Plugins - Development environment and tools needed
« Reply #21 on: August 22, 2018, 01:05:07 pm »
Anyway, I have a request. I think Visual Studio Code is one of the best open source Dev tool out there.
It is multiplatform and free.
It has Lua extension with intellisense and git integration.
Please consider a plug-in to integrate debug, publish scripts and you'll have the best result.
Vera Edge EU, Fibaro FGRM 222 (12), Fibaro FGS 223 (20), Fibaro FGS 222 (5), Fibaro Universal Binary Sensor (2), Fibaro Plug (3), NeoCoolCam Door Sensor (3), NeoCoolCam PIR (2), Nest (3), Home Server running my own integrations, Harmony Hub, OpenSprinkler, Personal Weather Station, Sonoff TH & more

Offline dmevis

  • Sr. Newbie
  • *
  • Posts: 41
  • Karma: +3/-10
Re: Vera Plugins - Development environment and tools needed
« Reply #22 on: August 22, 2018, 03:27:24 pm »

Regarding UX our strategy changed to a mobile first one.


NO! I do not want to be doing set up on a mobile device. I still want to do it with a keyboard and a mouse. Going mobile may be considered a move forward, but for speed and ease it is a move backward.

I agree!!!

We should give equal weight to both Mobile and Desktop!

I have found that as I am able to make my HA smarter and smarter, primarily using PLEG, that I have less and less reason to access either interface.  I prefer to do all system maintenance on the desktop, and I no longer use the mobile UI at all. 

Offline Dragos Perju

  • MiOS Official
  • Global Moderator
  • Sr. Newbie
  • *****
  • Posts: 48
  • Karma: +4/-0
  • Think different
Re: Vera Plugins - Development environment and tools needed
« Reply #23 on: August 23, 2018, 07:14:41 am »
Guys let's keep this topic related to what you, plugin developers out there need to get fixed or what new features you want in order to be happy and write new amazing apps or upgrade those that you already have.

I've put in motion the instantiation of a new web interface so all registered developers can have an input in our development roadmap. The idea is:

- spin up an instance of Jira or another tool
- all register developers will be able to create an account
- you will be able to add: defects, improvements and new features that will help you build plugin/apps
- you will be able to VOTE witch one is more important
- you will be able to watch the progress
- you will get access to pre-release builds to validate

The link is going to be available to all plugin developers in 1 week starting today.
Dragos Perju,
Product Manager @ MiOS

Offline Dragos Perju

  • MiOS Official
  • Global Moderator
  • Sr. Newbie
  • *****
  • Posts: 48
  • Karma: +4/-0
  • Think different
Re: Vera Plugins - Development environment and tools needed
« Reply #24 on: August 23, 2018, 07:45:49 am »
@Dragos

I have developed both of the current Vera pool plugins and I want to chime in on my perspective of the UI and the device contexts.   The mobile apps seem to focus on a single control per device which is not the case for many types of devices and I sincerely hope that this is not the direction Vera is headed.  I have included some items related to the pool control plugins to give you an idea of what I am talking about.  There are others including chemistry control, scene lighting, MagicStream, and pumps that have multiple controls affiliate with the single device.  If each of the controls had its own generic device panel the experience would just plain suck as my pool, for instance would have 50+ panels to control the pool and manage its functions.

The up/down increment control was broken by an errant css background setting in your core stylesheets so that is why the chlorinator now displays with goofy looking buttons. But this screensot closely represents what is required to control two types of devices attached to most pool automation.

Intellichlor --40 is a chlorinator device.  Associated with this are settings for both pool and spa mode indicating how much power to apply to the chlorinator as well as a shock cycle countdown that runs the chlorinator at full power for a period of time.

Spa Heat and Pool Heat are heater destinations not sources.  Although these look like thermostats they are not.  In most pool automation panels the heat source will switch depending on the current body being fed as well as the variants in the temperature and the equipment installed.  This also means that the thermostat device type is just wrong for both control and management.  For instance, if I had a heat pump tied to the heating panels would need to include the preferences for the operating heat pump to maintain the temperature of both the pool and the spa.  This is how Jandy and Pentair (the two most common) have automated their controls.  I presume this to be the same with Hayward but I have no experience with it.

At some point in the past it looks like the static JSON was going to contain all the metadata required to render the controls and define the behavior for the device, but somewhere along the line the focus changed.  Shortcomings in the static JSON were augmented with display and behavior based upon hardcoded functions of particular DeviceTypes.  A quick perusal of the javascript code reveals all these special cases.  Start at returnDeviceContainer then follow on from there as even Virtual Switch has special handling that changes the css, script, and the binding.

I guess what I am trying to say is that as a plugin developer I can never create a new device type that has features or functions needed for a complex device given the amount of effort that internal staff have placed into View.js & Interface.js.  Since DOMPurify is implemented getting over things like the broken css and extending the controls are impossible without rewriting a full UI as amg0 has done.  Who has time for that except maybe amg0. 

My hope is that the css gets fixed in the future and is part of your sprint.  If it doesn't I'll need hack the css file (The hover state works by the way).  Like rigpapa alluded to, not all the parameters in the static JSON are honored or do not operate the same based upon the device type.  When you are building a custom device type this also means that you can be pretty sure it won't work on the mobile device.

I am encouraged and hope to create plugin devices that will work on the mobile platform.  I can't wait to rework my plugins to try it out.  I hear people say that home automation isn't about control so you shouldn't need an interface.  There are things that Vera should do that involve control.  Here's just a few scenarios;  You are sitting in the backyard and simply want to turn on the water features.  You need to run a shock cycle overnight after 20 kids swam in the pool all day.  You want to turn on some lights because you have friends coming over.  That is control and not automation and these all require an effective interface.  It sounds like you are headed down the Bootstrap and maybe even the TypeScript path for your tech stack given your comments below.  Perhaps some theming is in our future as well as real powerful expansion of the UX. 

In the end, I created my plugins because I needed them myself.  I shared them in the hope that someone else might need them thus expanding the Vera herd.  There is strength in numbers so long as you are standing somewhere near the middle.  And I don't use the app store because turned out to be too much of a PITA to get the code published and I felt like it was time I would never get back.

As I mentioned in a previous post we are preparing a instance of a tool that will allow you guys to add defects, improvements and new features for the development environment.
Please bare with us until we solves the publication process for apps.

Your input is valuable and was added to our list. Do you have a way as of right now to tell how many people use you plugins?
Dragos Perju,
Product Manager @ MiOS

Offline rstrouse

  • Hero Member
  • *****
  • Posts: 836
  • Karma: +30/-9
Re: Vera Plugins - Development environment and tools needed
« Reply #25 on: August 23, 2018, 10:38:05 am »
I know how many times it has been downloaded from the thread and I have a pretty good idea of the heavy users. 

I can also keep multiple versions there.  Not as much of an issue right now but there was a period where UI5 code didn't work well enough for production on a UI7 system.  There was also a time ~fw v7.04 where the static JSON changes made all sorts of stuff display incorrectly.  I needed a version for pre- 7.04 and 7.05+.
1xVera3 1.7.619, 4xLinear WT00Z, 3xLinear WS15Z, 1xLeviton VRCZ4, 10xCooper RF9540, 1xLeviton VRFI10, 1xLeviton VP00R, 2xLinear GD00Z-4, 1xGE/Jasco 45612, 1xGE/Jasco 45610,  4xGE/Jasco 45605, 2xYale YRD220-ZW-619, 1xCaddx NX584, Autelis Intellitouch Pool Control, OpenSprinkler

Offline ceefin

  • Full Member
  • ***
  • Posts: 139
  • Karma: +6/-0
Re: Vera Plugins - Development environment and tools needed
« Reply #26 on: August 24, 2018, 02:32:17 am »
Scrub the documentation and make sure information is current.

I can't come up with any particular examples right now because it's been a couple years, but the impression I got while writing the Magic Home RGBW plugin was that there was a lot of outdated information on the wiki.

Also, get rid of the micasaverde moniker/domains on the wiki/everywhere else if 'Vera' is the brand name.

Offline a-lurker

  • Hero Member
  • *****
  • Posts: 860
  • Karma: +63/-8
Re: Vera Plugins - Development environment and tools needed
« Reply #27 on: August 24, 2018, 03:35:40 am »
  • Enforce the use of L_XYZ.lua files, rather than locating lua code in the I_XYZ.xml file, for all new or updated plugins. Mixing Lua code within xml is nasty. Compare the readability of the GC100 implementation file in the store, with this lua file where the lua code has been split out: http://forum.micasaverde.com/index.php?action=dlattach;topic=37268.0;attach=35252
  • Distribute a bit library or a more recent version of Lua, that includes same.
  • All scene Lua should be accessible/viewable in one file or on one web page. It's really difficult to keep track of what Lua is used in what scenes. I make all scenes call just one block of Lua code along the lines of this post: http://forum.micasaverde.com/index.php?topic=29627.0 That's OK for programmers but just being able to see all the Lua in one location would help debugging.

Offline jlind

  • Full Member
  • ***
  • Posts: 220
  • Karma: +10/-6
Re: Vera Plugins - Development environment and tools needed
« Reply #28 on: August 24, 2018, 12:53:40 pm »
I second the idea of seeing all of the scene code in one location.  Maybe not edit it in one place, but just to be able to see it to isolate where specific global variables are being used.  I used to be able to send myself a formatted email with it all organized but they've encrypted it now and I haven't been able to figure out how to decrypt it.
VeraLite/VeraPlus with UI7, Multiple GE switches, GE Outlets, Aeon Smart Switches, Minimote, GE Portable outlets  Apps: (Pentair Autelis Plugin, Weather Underground, Honeywell WiFi Thermo, System Monitor, AlternateUI)

Offline rigpapa

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 759
  • Karma: +115/-1
Re: Vera Plugins - Development environment and tools needed
« Reply #29 on: August 24, 2018, 01:02:36 pm »
I second the idea of seeing all of the scene code in one location.  Maybe not edit it in one place, but just to be able to see it to isolate where specific global variables are being used.  I used to be able to send myself a formatted email with it all organized but they've encrypted it now and I haven't been able to figure out how to decrypt it.

It's not encrypted, it's just base64 encoded. You can load the "mime" module and use the "mime.unb64()" function to turn it back into text.
Author of Reactor, DelayLight, SiteSensor, Rachio, Deus Ex Machina II, Intesis WMP Gateway, Auto Virtual Thermostat and VirtualSensor plugins. Vera Plus w/100+ Z-wave devices. Vera3 sandbox.