No comment 
I just need you guys to be slightly more lazy.. to the point where asking for this feature is too much work 
8 Likes
LOL!!! 
+1
I haven't touched my drivers for months.
Simply because I got tired of hunting down copy-paste bugs. If you tell me you put this feature to the end of your list with the lowest possible priority, that's enough for me. I won't ask for deadlines, I promise. 
Someone else will. 
1 Like
Reviving this old thread just to say that I do this using a Python script which can automatically re-use code for my drivers and then push the changes to the hub. With the script configured I press Build in VSC and just wait for the hub to be updated a few seconds later. Any errors during upload are caught and displayed in the console of VSC.
It was never really developed to be used by anyone besides myself, but maybe it might be worth adapting if there's interest and someone else also wants to share the development of this tool?
1 Like
Iād be super interested in seeing how you did this.
The script is on my GitHub together with my drivers for Tasmota 7.x:
As I mentioned, they were developed to be run by me alone, but could be easily made into a class and made much more reusable and useful to others. It uses eval() so it's not directly safe, but it works and I could write it quickly.
EDIT: I updated the code a bit, it is now in classes and should be useful to anyone who knows Python and wants to reuse code in their apps and drivers as well as to keep code/code snippets in multiple files and merging/reusing them for deployment. The upload/update of code function might also come in handy so there is no need for copy/paste and you can still work in the editor of your choice. I run this in Visual Studio Code, and it is like local compile/deploy. Very fast... If there truly is interest in this, I'll create a release thread...
4 Likes
I have started to develop drivers recently and I'm already very interested in your method @markus.
Being an OO programmer for over 20 years made me confirm that code duplication is the source of all evil. All the copy&paste involved in the regular driver development is hurting me badly.
1 Like
About a week into developing for HE I had enough and started to write on this thing so I understand what you mean 
It doesn't have documentation but it's all in there, if you need specific pointers ask away
1 Like
OK, that's a job for me!
Any news regarding the reuse of code (e.g. creating my own libs)?
For me something simple as an include directive would be good enough, that would be interpreted as a textual import. Example:
MyLibraryApp:
Contains some very sophisticated reusable methods... 
String translateToChinese(String german) {
...very very sophisticated code
}
MyFirstApp:
import MyLibraryApp
String chineseHallo = translateToChinese('Hallo')
MySecondApp:
import MyLibraryApp
String chineseGutenTag = translateToChinese('Guten Tag')
MyFirstDriver:
import MyLibraryApp
String chineseAufWiedersehen = translateToChinese('Auf Wiedersehen')
etc. pp.
1 Like
I just don't see this happening, as I understand it there's too much limitation on the sandboxed environment e.g. you can't create classes, where would you "load" your libraries to in order to be able to import them, etc.
You'd then have the same issue with "where" to host that file that needs to be Included. And driver / app management then becomes more involved because you have to upload both the driver / app file and all the "includes".
This can already be done at the source level using IDE / build tools, so doesn't really bring anything helpful to the table IMO.
I think Markus was using a complex Python build tool to build his drivers from segmented code files.
I use a more simple approach in VSCode, all my "common" code is in a separate file and I just use a VSCode task to merge that into my drivers, which are mostly just simple stubs. Ctrl-Shift-B and the drivers are built and ready for upload ....
1 Like
A "lib" would be just another app on my Hubitat.
That's an easy one:
Exactly there, where all my other apps are saved - on my Hubitat.
But that needs error-prone copy'n'paste actions...
And it's not an Hubitat only solution...
Sure but the platform isn't built like that, you can't "load" another App / Driver from code. When an App / Driver is saved in the editor it has to meet at least bare minimum framework requirements, you can't just save arbitrary code - try and save a file that doesn't -
Not sure what you mean by that, there's no copy'n'paste involved.
This is my task in VSCode.
{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "2.0.0",
"tasks": [
{
"label": "build",
"type": "shell",
"command": "${workspaceFolder}/hubitat/build/build.cmd",
"options": {
"shell": {
"executable": "C:\\Windows\\System32\\cmd.exe",
"args": [
"/d",
"/c"
]
},
"cwd": "${workspaceFolder}/hubitat/build"
},
"presentation": {
"echo": true,
"reveal": "always",
"focus": false,
"panel": "shared",
"showReuseMessage": false,
"clear": true
},
"group": {
"kind": "build",
"isDefault": true
},
"problemMatcher": []
}
]
}
And this is a single line from my build.cmd:
type ..\"Sonoff SNZB-01 Wireless Switch.groovy" ..\"Common Functions.groovy" ..\"ZigBee Framework.groovy" > "Sonoff SNZB-01 Wireless Switch.groovy"
The output is "Sonoff SNZB-01 Wireless Switch.groovy" which is a fully ready to go driver.
I also upload them to a local web server:
"C:\Program Files (x86)\PuTTY\pscp.exe" -P 22 *.groovy user@my.local.web.server:/var/www/html/hubitat
Each driver / app has the importUrl set:
importUrl: "http://my.local.web.server/hubitat/Sonoff SNZB-01 Wireless Switch.groovy"
As I said, Ctrl-Shift-B and all my drivers are built and uploaded ..... then it's just a case of hitting "import" on one of the Hubitat hubs to update the driver / app there.
3 Likes
Therefore the wish for a feature request...
Why don't omit error checking for apps that first line is just library (e.g.)?
BTW: Your VSCode solution is very sophisticated 
- but it has one disadvantage:
When you change the lib you manually have to do the import for all the apps that use this lib.
Sure, nothing is technically impossible, but based on staff response to feature requests of this and similar "developer" features I'd be surprised if you get anywhere.
Hence pointing out a solution that works today.
This really depends on your point of view. IMO I consider the manual import of each driver / app to be a benefit.
Typically if I update shared code portions I'd want to gauge their impact on a specific driver / app. If all drivers / apps were automatically updated to use the shared code portion that could be disastrous in a live environment.
In any case if you do want to do that then you can use one of the version control Apps like HPM - https://community.hubitat.com/t/beta-hubitat-package-manager or one of the build tools that others use - Command-line build tool (uploader) for Hubitat driver and app code
2 Likes
Good point!
I do too. I don't want to update driver A and have potential unintended impact on driver B. Annoys me greatly when it happens at the platform level, and I don't want to exacerbate that problem.
Maybe I'm just cautious though.
2 Likes
For my workflow at least, what I think I need is a Grunt or Gulp workflow (or another similar framework). It would:
- Parse through all my local repositories of Hubitat source code
- Anywhere it sees an #include statement, it would copy in the included file from my /includes folder
- The output would be treated as "compiled" code, and put in a separate folder.
Two more bonus tasks:
- Upload my compiled code onto my local hub
- Update my github repos with the compiled code and update my Hubitat Package Manager manifests for the projects.
That said, I don't have time to build this right now, so it is left as an exercise for the reader. 
3 Likes
Thought I'd add that I added code completion to VSCode for Groovy too using GitHub - prominic/groovy-language-server: A language server for Groovy
It's not perfect, but does mean that my own methods are now resolved and offered for autocomplete.
3 Likes
Finally my idea of libraries to reuse code is realized!
5 Likes
