Chocolatey option to install on Windows

[ghys]

Hi,
I recently thought openHAB could use a Chocolatey package for Windows, only to discover that @bcurran3 already made one 🎉 (kudos to you!)

https://chocolatey.org/packages/openhab

So a great option to have openHAB running on Windows very quickly (for instance to try it out locally) is to install Chocolatey and then simply do:

choco install openhab

so I'm opening this issue to consider it as an alternative in the Windows install instructions page.

I just tried it out of curiosity on a new machine without even a JRE installed and it worked flawlessly - took care of downloading, extracting and installing the JRE and openHAB 2.1, even adding a shortcut on the desktop and the start menu :)

I don't think it can perform upgrades between versions yet, though the PowerShell upgrade script (openhab/openhab-distro#473) could in part be reused for future versions. Another thing to note is, openHAB is installed to C:\ProgramData\chocolatey\lib\openhab.

[ThomDietrich]

That's great! @bcurran3 anything you want to add? Why did you never promote your work?
What are the limitations of this approach? Is a change of the location to C:\openHAB2 possible? Great work!

@AngelosF

[AngelosF]

so I'm opening this issue to consider it as an alternative in the Windows install instructions page.

Absolutely with you!
The current set of instructions for the windows installation (and service deployment) are far from perfect :)

I will test this choco package manager and provide feedback. So far, it looks great!

[bcurran3]

@ThomDietrich - Don't promote because it's just fun volunteer work. :) I've got a few hundred packaged up programs.

I can package the next release to install to c:\openHAB2. It's not a big deal at all. Before doing so, any particular reasoning there? Personally I hate filling up the root of my hard disk, I like all my programs put somewhere else. Since openHAB basically just extracts and runs, it's easy to throw with all the Chocolatey files. Since c:\programdata requires admin privileges, my script checks who the admin installer account is and adds rights to the openHAB directory so config files can be saved/modified easily. I like it there. I prefer it there, but strictly a personal preference and slightly easier to manage. If the general usership prefers it in c:\openHAB2, then so be it (on the next release packaging).

I guess I should promote the packages for the programs I package up in their respective support forums. :)

I can even add the update script for the dailies easily as long as the upgrade script itself is stable.

[bcurran3]

The nuspec and scripts can be found in my repo. Feel free to make a pull request if you see anything that could be better.
https://github.com/bcurran3/ChocolateyPackages/tree/master/openhab

[ghys]

@bcurran3 the upgrade script is meant to automate the non-trivial tasks necessary to perform an upgrade while retaining the user configuration. But currently it also downloads the openHAB distro from either cloudbees (for daily snapshots) or bintray (for stable releases); if the user is upgrading through choco those parts would be done by the Chocolatey cmdlets instead.

When you release a package for the next stable version (I'll assume you don't want to push packages for daily snapshots although it would be very cool 😛 ), please chime in so we can work together to ensure choco upgrade openhab performs a proper upgrade 👍

[bcurran3]

There is a Automatic Update (AU) system that the Chocolatey Core Team and other package maintainers use. I started looking in to it one night, late at night, and it looked like a convoluted mish-mash of various technologies that had way too much reading for me to take on and understand that night. At some point I will get back to it. It's basic premise is that it checks files on the web for new versions and then re-creates the package and pushes it into the Chocolatey public repository so that no program will be older than however often you run the update check script (Typically once a day.). Once I actually get it implemented, it will replace all the time taken up for all the packages that I manually update. At that point I'll look into the possibility of packaging dailies as well. No promises on my ability or how much time it will take, but it's on my personal roadmap.

When the next stable release of OpenHAB hits, I'll revisit what needs to be done for an upgrade versus a fresh install - any foresight would be appreciated.

[ThomDietrich]

(Related to #180 and maybe #365)

Hello @bcurran3 👋

you are absolutely right, there is no apparent reason to choose C:\openHAB2. The problem is, that parts of the openHAB folder will need write access by the user, parts are written to by openHAB itself. The folder in it's completeness is hence not suited for the C:\Program Files folder (as you already know). Putting everything into e.g. C:\ProgramData\openHAB2 would be an alternative but yet again, the openHAB binaries are not really suited for that location. Going with the very generic approach of C:\openHAB2 is the obvious option.

However with Chocolatey as an option to actually "install" openHAB nothing stands against dealing with these limitations. Just as in the openHAB Linux packages we could start to split up content into fitting places.

Compare: https://github.com/openhab/openhab-linuxpkg/blob/master/build.gradle#L220-L318 ( @BClark09 )

On a Windows system I could think of a segmentation similar to this:

• openHAB Binaries: C:\PROGRA~1\openHAB
• openHAB user config (conf folder): C:\Users\me\Documents\openHAB2
• openHAB user data (userdata folder): C:\Users\me\AppData\Roaming\openHAB2
• openHAB log files: ...
• Some Linux specific files can be deleted

If or if not to work in the context of one user could still be discussed.

In the process you could add shortcuts to the start menu for all these paths to make sure the user still finds them.

Additional/optional steps of the installer could be the automatic installation of the openHAB Windows service or the packaging of a log viewer.

What do you think? Would you be interested? How would you feel about moving this discussion over to your very own https://github.com/openhab/openhab-winpkg (to be created) 😉

[bcurran3]

In the case of the Chocolatey package and putting it in \programdata\chocolatey\lib\openhab, I assign rights to the installing user account in the script:

$WhoAmI=whoami
icacls.exe $toolsDir /grant $WhoAmI":"'(OI)(CI)'F /T | out-null

It probably doesn't work for everyone, but it probably works for most.

The suggested segmentation would look right for a typical program, but I don't see OpenHAB as typical. Since OpenHAB is basically a server, I don't see any advantage to it running multiple instances for people. I would suggest the goal should be making it run as a service and a shortcut in \Users\Public\Desktop to run the default browser and connect to the server for user interaction.

[ghys]

Since OpenHAB is basically a server, I don't see any advantage to it running multiple instances for people.

A fair point IMHO.
Also after reading https://chocolatey.org/docs/create-packages#installation-paths and https://chocolatey.org/docs/chocolatey-faqs#what-distinction-does-chocolatey-make-between-an-installable-and-a-portable-application the advice seems to be to use %ChocolateyInstall%\lib\mypackage or %ChocolateyBinRoot% and avoid Program Files unless the program being packaged has a full-fledged installer.

Wouldn't be the easiest to simply update this table in the docs and make it closer to this one for Linux?

i.e.

	Chocolatey (Package) Installation	Manual Installation
openHAB application	C:\ProgramData\chocolatey\lib\openhab\runtime	C:\openHAB2\runtime
Additional add-on files	C:\ProgramData\chocolatey\lib\openhab\addons	C:\openHAB2\addons
Site configuration	C:\ProgramData\chocolatey\lib\openhab\conf	C:\openHAB2\conf
Log files	C:\ProgramData\chocolatey\lib\openhab\userdata\logs	C:\openHAB2\userdata\logs
Userdata like rrd4j databases	C:\ProgramData\chocolatey\lib\openhab\userdata	C:\openHAB2\userdata
Service configuration	C:\ProgramData\chocolatey\lib\openhab\userdata\etc	C:\openHAB2\userdata\etc

Maybe with a shortcut to C:\ProgramData\chocolatey\lib\openhab in the start menu as a convenience, like @ThomDietrich suggested?
Another suggestion: since openHAB now recommends Zulu as a JVM would it be advisable to change the javaruntime dependency to https://chocolatey.org/packages/zulu?

[bcurran3]

In the Chocolatey package installation for OpenHAB, I do create a shortcut both on the desktop and in the Start Menu.

If Zulu is the preferred JVM, I can switch to that easily enough. (Just confirm please.) If OpenHAB 2.2 is close, I can switch to it in the next package release. If 2.2 is far out, I can update the current package.

[BClark09]

I'd agree that for a Windows installation it makes more sense to contain everything in the same folder path. Automatic Linux installations use the deb or rpm file path recommendations, so chocolatey installations should use C:\ProgramData\chocolatey\lib\ recommendations IMO.

Zulu is indeed the recommended JVM, Oracle-JDK comes with licencing restrictions that most likely wouldn't be fit for the usual home user. That's not to say that it should install Zulu if any JVM has been detected though.

Nice work @bcurran3!

[bcurran3]

I'm actually updating the Chocolatey package "as we type."

Of little importance: I'm updating it NOT to make a shim for karaf-service-win.exe.

Of probable importance - should the OpenHAB icon require Run as administrator? On Windows Server 2016 I get one UAC pop up when run as administrator but two UAC pop ups when the registry is read Seems to me that one user interaction is better than two.

I'm going to add the download of openhab-addons-2.1.0.kar and drop it in the addons folder as part of the package for the future.

I'm actually running into problems with the program. I keep getting "ERROR: 404 - Not Found" at least twice when I go to Paper UI. And getting

HTTP ERROR: 404

Problem accessing /basicui/app. Reason:

    Not Found
Powered by Jetty://

..for basicui.

This is a new install with port changed to 88 only. I've been changing file permissions with no success. Kind of lost here at the moment as i can't make it work. :( Weird thing is, it worked earlier when I extracted and ran manually. I'm thinking maybe the path is too long? . Ugh....sorry to go off track.

[ghys]

In the Chocolatey package installation for OpenHAB, I do create a shortcut both on the desktop and in the Start Menu.

Yes, I meant a shortcut to the folder itself (or the conf subfolder actually) named "openHAB Configuration Folder" or similar, which would open it with explorer.exe.
And if Chocolatey ends up installing the Windows Service automatically (maybe this could be an option like choco install openhab -PackageParameters "/installService" a little bit like the exclude 32/64-bit option of the jre8 package?), replace the shortcut to launch the runtime itself by one launching the default browser and navigating to http://localhost:8080 (as you rightfully mentioned)

[ghys]

Of probable importance - should the OpenHAB icon require Run as administrator? On Windows Server 2016 I get one UAC pop up when run as administrator but two UAC pop ups when the registry is read Seems to me that one user interaction is better than two.

I got those too (2 UAC prompts related to the registry on Windows 10). But only with your package, if I extract the openhab-2.1.0.zip and run start.bat I get no UAC prompts.

I'm going to add the download of openhab-addons-2.1.0.kar and drop it in the addons folder as part of the package for the future.

This step is actually optional, for offline installations, if it doesn't find the .kar files add-ons would be downloaded from the Internet as required.

[bcurran3]

Yes, I meant a shortcut to the folder itself (or the conf subfolder actually) named "openHAB Configuration Folder" or similar, which would open it with explorer.exe.

This could be easily done. Do you think it's that helpful? I just don't want to take flak for creating too many icons. In Start Menu, it makes sense to make a OpenHAB menu item with multiple shortcuts, I just think it might be too much to drop on the desktop.

And if Chocolatey ends up installing the Windows Service automatically (maybe this could be an option like choco install openhab -PackageParameters "/installService" a little bit like the exclude 32/64-bit option of the jre8 package?), replace the shortcut to launch the runtime itself by one launching the default browser and navigating to http://localhost:8080 (as you rightfully mentioned)

I have to read the docs for setting it up as a service, but I'm all for the option to do that.

I probably should create an icon to launch the default browser and go into the web UI.

I got those too (2 UAC prompts related to the registry on Windows 10). But only with your package, if I extract the openhab-2.1.0.zip and run start.bat I get no UAC prompts.

This is a problem, and I bet it's directly related to my personal problems running OpenHAB at the moment. I'm betting it is something to do with the file permissions or ownership. I'm going to tinker more and make it right.

This step is actually optional, for offline installations, if it doesn't find the .kar files add-ons would be downloaded from the Internet as required.

For the OpenHAB 2.0 Chocolatey package I had a 2nd package with the addons ready to go. Then when I saw OpenHAB downloaded and installed them so easily from the Internet, I self-rejected it thinking it just wasn't necessary. Right now I'm having problems and it helps to download it and throw it in there since things aren't working right for me. I need to fix the hypothetical file permissions problem and then I might make the addons a seperate addon package (though I have it downloading now in a revised script).

[bcurran3]

I probably should create an icon to launch the default browser and go into the web UI.

I'll probably rename the current openHAB icon "openHAB runtime" and create the browser icon as "openHAB GUI."

[bcurran3]

I got those too (2 UAC prompts related to the registry on Windows 10). But only with your package, if I extract the openhab-2.1.0.zip and run start.bat I get no UAC prompts.

Just installed and tested on my Win10 desktop and it doesn't pop up any UAC prompts. Yet, it still does on my Windows Server 2016. I've changed some permissions on the server, but it looks like the only difference is full access by which account was used to install the package. On my server it's domain\admin on my desktop it's domain\bcurran. Both have SYSTEM, local Administrators with full control and domain\Users with Read & execute by default. (Again, playing - on server I changed ownership to SYSTEM and gave domain\Users full control.) I'll do more experimenting later, it's 4 AM here now and time for some recreational reading and bed. :)

[ghys]

I think if we manage to make openHAB run as a service it will run as the SYSTEM account, so we won't have to worry about UAC anymore :)
I'll try to have a look at it later.

G'night :)

[ThomDietrich]

but I don't see OpenHAB as typical. Since OpenHAB is basically a server, ...

Why exactly? This doesn't make sense to me. openHAB is a program the user installs configures and uses. It qualifies as a typical program and should hence follow formalities known from windows software.

The installation method (chocolatey) shouldn't dictate a special installation path, even worse, a path containing chocolatey in the name. I do not see programs being installed into NSIS or Inno Setup subdirectories. What's the special importance of chocolatey and why do we want to enslave openHAB to it?

@BClark09 On Linux the apt/rpm packages distribute openHAB files into recommended directories. That is correct. However these are not dictated by apt/rpm but by the more general Filesystem Hierarchy Standard. A similar standard exists on Windows and openHAB as a mature application for the masses should follow these standards.

@bcurran3 In my example above I mentioned a users specific AppData folder. That was wrong. I agree. I never intended to indicate that multiple instances are of interest. The folder C:\ProgramData is intended for application specific data unrelated to a specific user and would hence be indeed the right place for openHAB it seems. Additionally we should still discuss if the openHAB binaries should be moved to the C:\Program Files directory (the user and potential threats shouldn't have write access to these). I would strongly argue against the solution inside the chocolatey/lib directory.

I believe the service to be a crucial part of the installation, great you've already discussed 👍

I'll probably rename the current openHAB icon "openHAB runtime" and create the browser icon as "openHAB GUI."

Regarding shortcuts I believe there should be three:

• openHAB Dashboard (that's the official word for the starting page)
• openHAB Configuration (the conf folder, wherever it is located)
• openHAB Logging (this one could be a folder link but would ideally be a link to a preconfigured tail like application.)

In the start menu you could add additional links to the community forum and the docs page.

You didn't yet answer on this one:

How would you feel about moving this discussion over to your very own https://github.com/openhab/openhab-winpkg (to be created) 😉

[BClark09]

Fair points as usual @ThomDietrich! I'm a little less clued up on the specifics, especially for windows but my agreement was generally for use of being inside C:\ProgramData, indeed it does seem a bit strange to place a full application inside another applications' path. I also think that the binaries would be fine placed inside C:\Program Files, but I did like chocolatey's arguments for it's defaults.

In the start menu you could add additional links to the community forum and the docs page.

Would it be worth adding the console here too (client.bat)?

[ghys]

Additionally we should still discuss if the openHAB binaries should be moved to the C:\Program Files directory

https://chocolatey.org/docs/chocolatey-faqs#why-doesnt-a-package-install-software-to-program-files
I think they wouldn't be too happy during the review process to see a package pending moderation going explicitely going against their recommendations. Anyways, my 2c 😁 Maybe @bcurran3 as a seasoned Chocolatey package maintainer can explain why they do it like this...?

I found the reason for the UAC prompts - the runtime/bin/karaf.bat script in the distro wants to launch regedit.exe multple times for some reason (finding a JRE apprently):

start /w regedit /e __reg1.txt "HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\%JavaTemp%"

Unrelated: is there a way to get the Karaf service wrapper feature installed without SSHing into the console? Or would it make sense to package a pre-configured service wrapper inside the Chocolatey package?

[BClark09]

I found the reason for the UAC prompts - the runtime/bin/karaf.bat script in the distro wants to launch regedit.exe multple times for some reason (finding a JRE apprently):

It'll only do this if JAVA or JAVA_HOME environment variables aren't set. I'm assuming you no longer get UAC prompts if you set JAVA_HOME?

Or would it make sense to package a pre-configured service wrapper inside the Chocolatey package?

Absolutely, this is what linuxpkg does.

[ThomDietrich]

but I did like chocolatey's arguments for it's defaults.

https://chocolatey.org/docs/chocolatey-faqs#why-doesnt-a-package-install-software-to-program-files
I think they wouldn't be too happy during the review process to see a package pending moderation going explicitely going against their recommendations.

I've looked at this recommendation just now. I'm unsure how I feel about it. These arguments are not really strong in my opinion. I began to wonder if a real installer would in fact be the better choice for openHAB?

[ghys]

@BClark09 you hit the nail on the head. Setting JAVA_HOME solves this issue. It's on my machine with the JRE installed by Chocolatey, I wonder why it wasn't set, the Oracle JRE installer should have done it? Weird.

I've looked at this recommendation just now and began to wonder if it would indeed be an option to create a real installer for openHAB?

Agreed. openHAB is meant to be running as a daemon/service so it doesn't really match the definition of a "portable app"...
Edit: then again, distributing it as one is a great way for people to try out openHAB on their local machine easily before deciding its final location (openhabian, or another permanent option).
Edit2: I think the reasoning behind it is, if the vendor provides an installer with a default installation path, then the vendor has its way; if the software is a .zip archive you can extract and run from anywhere, then it's (in their view) a portable app, in that case Chocolately does its thing and manages it under its directory tree. Ergo, openHAB should have an installer ;)

[bcurran3]

@BClark09 you hit the nail on the head. Setting JAVA_HOME solves this issue. It's on my machine with the JRE installed by Chocolatey, I wonder why it wasn't set, the Oracle JRE installer should have done it? Weird.

Agreed. weird. My Windows Server 2016 app server VM doesn't have this value set, my every day Windows 10 machine does. Both should have had the JVM installed by Chocolatey. Keep in mind that they were installed at different times and thus different packages and versions.

https://chocolatey.org/docs/chocolatey-faqs#why-doesnt-a-package-install-software-to-program-files
I think they wouldn't be too happy during the review process to see a package pending moderation going explicitely going against their recommendations.
I've looked at this recommendation just now. I'm unsure how I feel about it. These arguments are not really strong in my opinion. I began to wonder if a real installer would in fact be the better choice for openHAB?

The way I packaged up openHAB for Chocolatey it is a portable app as it's just unzipped and left to be ran later. There is no reason why a 2nd package couldn't be created for install as a service. This is a good idea as the "portable" installation is perfect to try out and the service installation is better for permanent use. I would prefer the service implementation myself and will go this route.

Regarding shortcuts I believe there should be three:

openHAB Dashboard (that's the official word for the starting page)
openHAB Configuration (the conf folder, wherever it is located)
openHAB Logging (this one could be a folder link but would ideally be a link to a preconfigured tail like application.)

Just consider this done for the next Chocolatey package. A link to the documentation should definitely be there as well. MUCH NEEDED!

but I don't see OpenHAB as typical. Since OpenHAB is basically a server, ...
Why exactly? This doesn't make sense to me. openHAB is a program the user installs configures and uses. It qualifies as a typical program and should hence follow formalities known from windows software.

The installation method (chocolatey) shouldn't dictate a special installation path, even worse, a path containing chocolatey in the name. I do not see programs being installed into NSIS or Inno Setup subdirectories. What's the special importance of chocolatey and why do we want to enslave openHAB to it?

But openHAB IS a server! It has remote web and native clients that access it. Sure, it can be used just on one computer and nothing else, but it's usefulness extends to the ability to control things remotely through openHAB from any device, this a client/server scenario.

For it to follow formalities known from windows software, it shouldn't be documented/recommended to install to C:\openHAB2. :)

Chocolatey doesn't dictate a special installation path. Chocolatey is just really a collection of helpful scripts to go and download programs then install them. Native installers put things in the location that developers intended. "Portable" packages are up to the packager/scripter. Unzipping files to \programdata\chocolatey\lib\programname\tools is just easy to do with little scripting. A packager can put the files anywhere, it's just extra lines of script. By keeping it with the other package files, it's also easier to uninstall/delete as Chocolatey will remove the directory and files when told to remove the package. Again, just easier as the packager doesn't have to go write an uninstall script to find files elsewhere when they will be automatically removed by default with the package files. It comes down to laziness and the fact that the location of the files shouldn't matter if the shortcuts work and the user has permissions to the files.

openHAB has no enslaving to Chocolatey at all or anything else. I'm the packager/maintainer - it's a simple request to have it put elsewhere. I'm open to it and helping openHAB succeed/gain traction/etc. Keep in mind that I'm not part of the openHAB or Chocolatey team. I'm just a friendly volunteer trying to spread the word and make use of programs that I have some sort of nonvested interest in. I currently maintain almost 300 packages of which openHAB is but one. I'm here because I'm happy to make the package better and interact with the team to make things even better.

openHAB would GREATLY benefit from an actual installer. It would make all of these issues go away as everything could be handled by the installer. My Chocolatey package would just download the .EXE or .MSI to install and everything would work.

[ghys]

Maybe openHAB could have 2 packages, actually :)
openhab.portable to try it out with no system-wide changes, to see if it works for you;
openhab.install to have it properly installed on your system in the right places, including a service, by a potential future installer

[bcurran3]

Yes. That's what I was thinking would work for the time being.

[ThomDietrich]

Hey @bcurran3 👋 thanks for all the work you are putting into that package. I think users will greatly benefit from your work as soon as the project is mentioned in the documentation. All my comments were aimed to start a discussion about possible improvement to your already great start. I did in no way intent to insult or annoy you or discourage your ambitions. Sorry if my comments came around a bit bold.

I'm already happy if you take my comments into consideration. Happy Hacking! ;)

[bcurran3]

@ThomDietrich no worries and no offense taken.

Count me in to make the Chocolatey package as best it can be and I'm completely amicable to take any and all suggestions from the guys who created it.

I finally got openHAB 2.1 working for me last night. Still waiting on Nest and Insteon 2.x addons that work though. :)

Prost!

[bdleedy]

@bcurran3

For it to follow formalities known from windows software, it shouldn't be documented/recommended to install to C:\openHAB2. :)

Let's be honest, openHAB isn't installing like a typical program, it's unpacking files. Most Java programs like this are simply unzipped into the root. However, I do feel that something like C:\Program Files (x86)\openHAB would be a better folder except for the 'no spaces' thing. I feel like ProgramData is a terrible idea.

[ThomDietrich]

@bdleedy did you read the rest of the comments? C:\Program Files (x86)\openHAB will not work because this path is write protected in windows by design. Looking at all the facts you'll realize that ProgramData is the best location. The root (C:\openHAB2) was chosen in the past because no destination was easy to choose.

openHAB isn't installing like a typical program, it's unpacking files

There is a fine difference and with the windows service and start menu entries and other things coming, this effort is getting closer and closer to being an "installation".

[bdleedy]

I did read and understand them. That's why I said 'something like' and 'except for'. I don't consider the write protection an insurmountable issue either...

There is a fine difference and with the windows service and start menu entries and other things coming, this effort is getting closer and closer to being an "installation".

...especially after you say something like that... Right? If it's moving towards 'installation', at some point it's going to be an 'installed application'. Btw, I agree and I am excited that it's moving in this direction.

[bcurran3]

I see 2.20 is out. I've made the Chocolatey package but putting it on hold for a day or two to review this thread and implement any changes.

TDL:
change to zulu for JVM (right?)
add icon to config fold or browser to launch config.

Give me your wishlist before I "set this in stone" please.

[ghys]

@bcurran3 Great!
I can't comment on the JRE switch to Zulu because I never tried it on Windows...

add icon to config fold or browser to launch config

Nice! 👍
By the way: you might have noticed openHAB has a new logo, since you (I suppose it was you?) updated it on https://chocolatey.org/packages/openhab, so I trust your new package will have the tools/openhab.ico icon updated as well? :)

Thanks for doing this!

[bcurran3]

OK. I've updated the openHAB 2.2.0 Chocolatey package.
https://chocolatey.org/packages/openhab/2.2.0

• I think I got the right icons used, please verify
• stayed with Oracle JRE (4,646,370 downloads) vs Zulu (574 downloads) as Oracle is more popular
• downloads the addons
• openHAB shortcut FOLDER created with following shortcuts
• openHAB icon
• openHAB Dashboard icon
• openHAB Community icon
• openHAB Configuration Folder icon
• openHAB Console icon
• openHAB Documentation icon
• openHAB Logs icon

I did NOT offer the option to install as a service. This is very complex per the instructions at https://docs.openhab.org/installation/windows.html#starting-openhab-as-a-service. I don't know a way to issue commands into the OpenHAB console via the PowerShell script. I am open for suggestions if you can think of a way to do it...

Please take a look at it and see if the description, icon(s), or anything should be changed. I ran with the old description. I think I have the right icons, yet the site icon and the program icons are different. So I'm a little confused.

For those on Windows, please test it.

Chocolatey moderators are taking 2 weeks+ to approvate packages, so any changes are easy to do before it becomes "set in stone" and live for the "masses."

[ThomDietrich]

@bcurran3 great work!

Zulu Java is the default recommendation on Linux as openJDK poses certain incompatibilities and Oracle Java is problematic in it's licensing terms. While a defaulting to Zulu could be discussed I guess Oracle Java is just fine for your package. I'd say we can ignore this for now.

Your work is highly appreciated but I fear underrated. You should seriously consider drafting a pull request to mention it at http://docs.openhab.org/installation/windows.html, otherwise the majority of users will miss it.
You could restructure the existing article so that the existing headlines are underneath "Manual Setup", add a headline "Guided Setup"/"Automated Setup" above.

Regarding the listing: It feels to me like the data given doesn't clearly differentiate between openHAB as a whole and the chocolatey package by you. "Release Notes" should probably point to the chocolatey package release notes!? Once again I wonder if it would be a good idea to create a dedicated GitHub repository for the package...

[bcurran3]

Thanks @ThomDietrich.

Packaging is pretty easy. I've packaged a few hundred programs and have lots of templates now. :) It's just simple scripting.

Zulu vs Java: IMHO I think you're looking at this issue from a developer standpoint (and with Linux eyes). In the Wintel world, Oracle's Java is the defacto standard. To the majority, there is no such thing as a choice or any other versions. The normal Windows end user doesn't read EUL's and, in their eyes, once the software is installed and working there is no license. (Exceptions being developers and lawyers.) I've been working as a computer professional since the 80's, I've never seen a version of Java installed on a PC other than Sun/Oracle's. (BTW: Scott McNealy was sooooooooo ahead of his time with "The Network is the Computer" - if he would have used the friendly term "cloud," maybe people would have believed him back then.)

I will look into doing a PR to add to the documentation later when I'm having a normal sleepless night.

The Chocolatey package is all about the program, but the info about the package is there too. There are many links including:
Package Source - https://github.com/bcurran3/ChocolateyPackages/tree/master/openhab
Package Notes - https://github.com/bcurran3/ChocolateyPackages/blob/master/openhab/readme.md
Program Release Notes - https://github.com/openhab/openhab-distro/releases

I've been volunteering time doing Chocolatey packages for about two years or so now. I've packaged up programs that I use. I've packaged up programs that customers use. I've packaged up techie specifc programs. I've packaged up IT specific programs. I've written Chocolatey specific 3rd party add-ons. I've packaged up junk. A year or so ago I decided to put begs for donations in the read.me's. A year later, no one has bought me a single beer. :( I do it for me. :)

[ghys]

Hi @bcurran3! - just to let you know openHAB has a new 2.3 release, and a new website - now installing with Chocolatey is described as a alternative on https://www.openhab.org/download/ if you select Windows as your operating system :)
So it would be great if the latest version 2.3 could be packaged - this has been mentioned here: https://community.openhab.org/t/how-to-install-openhab-2-3-0-with-chocolatey-on-windows-10/46161
and @rkoshak has also offered to help. Thanks!

[bcurran3]

Thanks for the update.
Done!
https://chocolatey.org/packages/openhab/2.3.0

When new versions of openHAB come out...well, I'll get e-mails if posted here, ditto if I'm mentioned somewhere. Also you can just open an issue requesting an update at https://github.com/bcurran3/ChocolateyPackages/issues

[AngelosF]

should we close this issue?

Thanx @bcurran3 for the recent update!

OH 2.4.0 is around the corner, so we will need your help again soon :)

[bcurran3]

Easy 'nuff. I'm all in. Just give me a shout somewhere for me to know it.