Getting Started with openHAB

openHAB is an open-source home automation project, aimed to be vendor and technology agnostic. It integrates with all kinds of devices and platforms. It also allows you to create rules and scripts to trigger when certain conditions are met. It offers a simple, built-in UI and native apps for Android and iOS. In this post we’ll look at what it takes to get up and running with openHAB and start communicating with an Insteon device.

The first step is to download the openHAB runtime core and addons. The runtime core has all the guts to get the system up and running. The system is Java based so you’ll need Java installed. This also means it should work on any platform that supports Java. The addon package allows you to selectively choose what openHAB loads so you only have the components that you really need in your system.

Runtime and Addon Downloads

Runtime and Addon Downloads

Another handy little tool to download is the openHAB Designer. It has some syntax highlighting and validation for the openHAB file types and reads the openHAB directory structure to present it in an IDE-like fashion.

designer

After you’ve downloaded the packages, unzip the runtime core package to a good location. Once this is extracted, you’ll want to bring in the addons that you require for your configuration. The addons come out of the addon package and individual ones can be plopped into the addons directory of the runtime core folder structure. I only needed Insteon but grabbed a couple other ones. To integrate with various systems, you’ll want the “binding” addon for that system. The binding has the knowledge of how to communicate with that system. I also grabbed a couple persistence addons. These allow you to configure data persistence of the devices in your home for reporting. They aren’t required for the system to function.

Addons Directory

Addons Directory

Once the addons are installed, you’ll want to create a new configuration file for openHAB. In the configurations directory, you’ll need to create a copy of openhab_default.cfg and rename it openhab.cfg.

configs

You can then change all the settings you need for various bindings, persistence or the system in general. Each of the bindings have examples in the cfg file so you can just uncomment the line and move ahead. Here’s the configuration for my Insteon PLM. It’s connected to a USB (COM4) port on my machine.

plmbinding

Next, you’ll want to setup devices and groups. This is accomplished by creating a .items file in the items folder. It can have any name as long as the extension is .items. Groups are just logical groupings and can be nested. Items are actual devices located throughout the house. They can be part of multiple groups. For example, my basement lights are part of the basement group and the lights group. A full description of the items file syntax can be found on the openHAB wiki. Here’s an example of my .items file open in the openHAB Designer.

items

Once items are configured, you’ll want to setup a sitemap. A sitemap defines how the UI of your openHAB setup will look. There are a bunch of controls like text, switches, selections and images. For a full list, check out the openHAB wiki. It seems pretty simple but I’m sure with a complex configuration it can get pretty gnarly. Here’s a simple sitemap that has a single page with a switch to turn off and on my basement lights.

sitemap

After all this is configured, you can start up the openHAB server by running setup.bat in the root folder. Once running, you’ll be able to access the UI through a web browser at http://localhost:8080/openhab.app.

webapp

They also offer a Android and iOS app. I installed it on my phone and had to configure the external\internal URL. If you didn’t setup credentials (which is by default), you can leave those blank. Once connected it looks very similar to the web app but native to the phone.

IMG_1333

So far, it looks like a really neat solution. It turns on and off my basement light just fine; even from my phone. It’s a bit of a learning curve getting started but seems really powerful. I have a few more Insteon devices lying around that I’ll get hooked up so I’ll see how that progresses. Apparently, it can integrate with Nest as well so I will have to get that up and running too.

 



Reading Temperature from a Google Nest Thermostat with PowerShell

I recently acquired a Google Nest thermostat (on sale at Target!). Even before buying one I was already thinking about the automation possibilities. Google provides a REST interface for the Nest device. It’s accessible via OAuth and very easy to consume. The core tenant of their API is that there are very few endpoints and a single data model for multiple devices. In this post we’ll look at how to get up and running with the Google Nest REST API.

nest

First, you need to create a developer account. Once this is done you need to create a new application under your developer account. It asks you a few questions about the types of devices and permissions you’ll need and from there you are ready to start interacting with your Nest device.

application

On the right hand side of the application page, you’ll see a couple text boxes with some key information in them. The first Authorization URL box would be the URL that you send the end user to. This prompts the user to authenticate and give permission to the application to access their device.

oauth

After clicking accept, the user will be presented with a PIN code page. This PIN needs to be provided back to the calling application. It will be inserted into the Access Token URL in place of the AUTHORIZATION_TOKEN portion of the URL provided in the Authorization Token URL on the application page.

pincode

The application, or PowerShell in this example, can then invoke the access token URL with the authorization token and it will receive an access token. This access token can then be provided to the various endpoints available in the Nest REST API.

Below, you can see the first command receives the access token, Next, it calls the devices endpoint with the auth key set to the value of the access_token. The returned value is the devices data model that includes all the information about the devices accessible to the calling application and tied to the specified user’s account. As you can see, I returned the current state of my HVAC system and the ambient tempature surrounding the thermostat.

PowerShell

There’s tons of nifty information for each device. There are also a bunch of cool devices to interact with.

permissions

There is also the ability to work with virtual devices so that an actual device isn’t needed. It’s pretty sweet to see this type of home automation so simply accessible. I hope to stumble upon some new devices in the near future and come up with some cool integrations.



Digging into PowerShell Direct

Available in Windows 10 and the Windows Server 2016 Technical Preview, there is a new feature of PowerShell and Hyper-V that enables you to connect to guest machines that lack network access: PowerShell Direct. The standard PSSession cmdlets along with Invoke-Command now offer a VMID and VMName parameter. Simply run any of these commands as you normally would with a remote machine and you have access to a remoting session to the guest. It worked perfectly for me.

powershellDirect

After playing with it a bit, I was curious to find out just how it works. The first place I looked was in the guest where there is a new service installed called the “Hyper-V VM Session Service” (vmicvmsession). It’s initially stopped but when I attempted to connect via Enter-PSSession from the host machine, the service was automatically started.

On the client end, I popped open .NET Reflector and dug into the Enter-PSSession cmdlet. This cmdlet can be found in the System.Management.Automation.dll. This is where you will see the new properties for VMName and VMID.

enterpssessionCode

When a VM name or ID is specified, a new HyperVSocketConnectionInfo class is used rather than the typical WSManConnectionInfo class.

connectionInfo

There were a bunch of interesting classes associated with Hyper-V remoting. They implement the glue necessary to open the connection and allow the PowerShell remoting proctol to go over the Hyper-V socket.

classes

One class that is interesting is the RemoteSessionHyperVSocketClient class. It’s responsible for initiating the socket connection to the guest. In the constructor to the client, it instantiates a HyperVSocketEndPoint to pass to the Socket constructor.

remoteSEssionConst

Interesting to note is the protocol type is listed as ICMP and the socket family is a 0x22 magic number. Looking at the AddressFamily enumeration, this address family is not listed. Also, the address family is not registered with IANA. The endpoint’s serialized value is a combination of the address family, VMID and service ID. The service ID depends on whether or not this is the first connection to the guest.

endpoint

On the first connection, the first step is to send the username and domain name.

sendUsername

Next a string is sent to indicate whether or not a password will be sent and then the password is sent. Afterwards, the client checks for a failure string.

password

Once this socket is open, standard PS Remoting protocols seem to be used just as you would with a WSMan connection.

Overall, it’s a super handy feature and it’s interesting to see how it’s being accomplished. I do wonder what the magical address family 0x22 will be called or if it will remain 0x22.

 

 

Upcoming features in PowerShell Tools for Visual Studio

Long time no blog! I wanted to showcase a couple neat features coming to PowerShell Tools for Visual Studio. My hope is that we can get some feedback before pushing to the gallery for the world to enjoy.

Windows Forms Support for PowerShell

The Windows Form designer is handy for throwing together some drag and drop UI. I spent some time futzing with creating a CodeDOM provider for PowerShell. The Windows Form designer talks CodeDOM so we need to translate the PowerShell AST into a CodeDOM format in order to get the form designer to understand a PowerShell script. The other half of the equation is taking an existing CodeDOM and translating it into a functioning PowerShell script. Some of the challenges were that, until recently, PowerShell didn’t support classes so we had to fake it. Right now the CodeDOM provider is targeting PowerShell v3+. It uses the AST to create CodeDOM CompileUnits.

Once you have the latest build installed, you will have access to a new item template (need a new icon!).

itemtemplate

Adding a new file of this type will create two files on disk. One is the designer code. The other is the event handling and execution file. The designer file contains all the code to render the UI and hook up the event handlers found in the other file. The execution file invokes the designer code and then shows the UI.

Designer

Designer

Execution

Execution

The designer file shouldn’t be edited by hand. The form designer is using the PoshTools CodeDOM provider to generate that on the fly.

Double clicking the form in the Solution Explorer window will show an error. Still trying to nail this one down!

Error

To fix the error, just add references to System.Drawing and System.Windows.Forms.

From there you should be able to drag and drop items from the Toolbox on the form. Adjusting the properties should work. You can also hook up event handlers by doing actions like double clicking on buttons.

Would love to hear feedback! I need to fix the issue with the references before this will be committed to the main branch.

PowerShell Command Explorer

One of the neat tools in the PowerShell ISE is the command browser. It allows you to view different modules and the module within them. It also allows you to select different parameters and sets, view help and execute commands. Well thanks to Erwin de Vreugd, we now have that functionality within PoshTools!

After installing the updated build, you can access the Command Explorer by naviation to View->Other Windows->PowerShell Command Explorer. It provides very similar functionality to what is in the PowerShell ISE. This feature is looking very complete and will be merged into the main branch in a couple days. Check it out below!

Please play and provide feedback.

PowerShell Tools for Visual Studio – What’s new?

What’s been going on?

Over the past couple of months I’ve been working with an awesome team of developers and project managers over at Microsoft to bring some great new features and fix a lot of bugs in PowerShell Tools for Visual Studio. The first pull request from the Microsoft PoshTools fork was pretty large.

pullrequest

 

They’ve been very busy opening and closing issues as well.

issues

x64-Bit Support

The most significant feature that was introduced is x64-Bit support. As you may be aware, Visual Studio is a 32-bit process and will be for the foreseable future. Before this release, the PowerShell runspace was hosted inside the DevEnv.exe process. This lead to the inability to use 64-bit modules or PowerShell features. Once DSC was released and became popular, it was pretty important to implement this functionality. The team at Microsoft developed an out-of-process PowerShell host that now starts up with Visual Studio when PoshTools is installed. All the IntelliSense, debugging and classification services utilize WCF to communicate with the host process. DSC, Workflow and 64-bit modules, like SharePoint, are now supported in PoshTools. It also means better support can be built for cross-language debugging between .NET and PowerShell. This was something that was impossible when the host was maintained within DevEnv but, with a little work, could be achieved with the new architecture.

configuration

Configurations no longer show red squiggles!

Remote Session Support

Additionally, the PowerShell host now supports remote sessions. You can enter a PSSession with Enter-PSSession or by using the icon located in the REPL window.

remote_session

 

 

New Look and Feel

The default syntax highlighting has been updated to match the ISE. You can always update your syntax highlighting as you see fit by using the Fonts and Colors dialog in the Options window of Visual Studio.

colors

We’ve also introduced all new icons developed by the UX team at Microsoft. Much better than what I was drawing in paint. 😉

icons

Finally, we reorganized the project properties dialog to be easier to work with. All the same options are available but on different pages.

project_props

 

Visual Studio 2015 CTP6 and Windows 10 TP Support – No more VS2012 Support

We made some changes to the extension manifest to allow for installation into VS2015 and Windows 10 preview builds. The extension continues to work in previously supported configurations, aside from VS2012. With VS2015 in the near future, it was decided to drop support for VS2012. We would love to hear feedback as to whether or not this is a big deal for the community going forward.

Compatibility with Python Tools for Visual Studio

A lot of the code that for the project system and the entire REPL were direct ports of code found in Python Tools for Visual Studio. Because of this, some GUIDs were reused and would cause problems when both extensions were installed. This has been cleaned up and now both extensions should live in harmony together.

TONS of bug fixes

There were fixes ranging from breakpoints only being hit once to scripts that were slow to type in due to the function drop down list. We’ve done some work to hit the most impactful issues and hope that you can see a more refined extension as a result. There are still open issues that we are tracking but will continue to work to knock that number down. Please don’t hestitate to open issues of your own.

Happy PowerShelling!

I encourage you to go out and try out latest beta build. We hope to gather some feedback on the new features and experience before publishing to the Visual Studio Gallery. Please feel free to submit issues or even pull requests.

 

PowerShell Tools for Visual Studio – Now 100% more free!

UPDATE: Just download the Visual Studio 2013 Communtiy edition and PoshTools works perfectly with it!

Recently, the Python Tools for Visual Studio team released support for Visual Studio Express 2013. After emailing the team, I found that there is a white list of extensions that are allowed to be installed in Express. Unfortunately, this is an internal Microsoft process and not available to external developers. Although this was a bummer, they pointed me once again towards the Visual Studio Isolated and Integrated Shell. I had previously experimented with the Isolated Shell with little luck and didn’t pursue it until a nudge from the PyTools team. Rather than having to create an entire Isolated Shell environment, you can instead download and install the Integrated Shell. It provides the entry point to launch the components provided by the Isolated Shell. It certainly was confusing to me but I gave it a shot. Success! You can download and install both the Isolated and Integrated Shells and then install PowerShell Tools for Visual Studio. 100% free!

Installation Steps

1. Download and Install the Isolated Shell
2. Download and Install the Integrated Shell
3. Open Extensions and Updates…
4. Install PowerShell Tools for Visual Studio

Black magic:

isolated_shell

So far, it looks like there are a couple features that aren’t working quite correctly.

– Debugging doesn’t seem to work as expected. This really limits the functionality and I’ll be looking into it.
– No built in source control integration. This sucks but is just a limitation of Isolated Shell. There are extensions for Git and SVN available on the gallery.

Otherwise, things stuff as IntelliSense, REPL, Syntax Highlighting and the project system seem to be behaving.

Feel free to try it out and look forward to updates in the near future.

PowerShell Tools – v0.8.0 – Now with REPL!

Today, I’m announcing the release of PowerShell Tools for Visual Studio v0.8.0. There are some important installation changes in this version and I want to make sure people are aware. You can download the latest on the Gallery (2012\2013) or via GitHub.

Installation Changes – Important!

The extension has been broken into two different editions based on Visual Studio version. This was done to fix installation issues caused by how the extension was being built. Building a different version for each version of Visual Studio has corrected this. For Visual Studio 2012 users, you’ll need to uninstall your current version of the extension and install the new version. Installing them side by side will cause issues. This should be the only time you’ll have to do something like this.

REPL Window 

This version adds an interactive REPL window. The REPL window is based on the same REPL that is integrated with the Python and Node tools for Visual Studio. You can run commands just like you would in any other PowerShell command window. You can access the window via View->Other Windows->PowerShell Debug Interactive. Output from your PowerShell scripts now goes to this window rather than the Output pane.

2014-06-15_17-29-18

Minor Bug Fixes and Changes

  • Fixed test discovery
  • Removed Project property pages because they were not actually functional
  • Added $DTE variable for StudioShell support and automation accessibility

PowerShell Tools for Visual Studio Thanksgiving Special!

In celebration of the Thanksgiving holiday (and because I finished a bunch of cool stuff), I’ve released a healthy update to PowerShell Tools for Visual Studio to the Gallery! There have been a lot of enhancements to the extension. I’ll highlight some of the key features in this post.

Unit Test Adapter

This particular feature I’m pretty excited about. It exposes Pester support to enable authoring of PowerShell-based unit tests that are discoverable and executable via the Test Explorer window. The adapter picks up on Describe blocks and allows you to execute them as a set or individually. When a test fails, the stacktrace and error message are presented in Test Explorer. This should also allow you to run your unit tests during CI builds in TFS. Pester support requires Pester to be installed on the module path. PoshTools does not include it at this time.

pestertests

 

Data Tips and Watch Window 

One feature I love in Visual Studio is the ability to hover over a variable and see it’s value. The newest version of PoshTools now has this functionality! It supports arrays and hashtables (unlike some of the interim GitHub releases). It expands multiple levels; just like other managed languages.

datatips

 

In addition to hovering, you can specify variables in the watch window. Handy!

watch

 

Dark Theme Support

The last time I promised dark theme support, it was a lie (like the cake). I had implemented it incorrectly. This version now correctly supports the dark theme. If you are still having problems with the dark theme after an upgrade, make sure to reset your colors to default for the dark theme. The colors for the dark theme aren’t as vibrant as they were (if it worked for you) but they correctly change when themes are switched. You can still update your own colors for the theme.

setdefaults

 

Read-Host

I’ve also added support for Read-Host. You’ll get this handy dandy input box to specify anything you desire!

readhost

As always, this release is available on both GitHub and the Visual Studio Gallery.

 

Execution Policy in PowerShell Tools for Visual Studio

I’ve had several people report issues with PowerShell Tools for Visual Studio behaving differently than the NuGet console. After some investigation, I’ve found that NuGet actually resets the process scoped execution policy to RemoteSigned if it is not Unrestricted, RemoteSigned or Bypass.

This is taken from the NuGet source for the VSConsole.

      private static void SetupExecutionPolicy(RunspaceDispatcher runspace)
        {
            ExecutionPolicy policy = runspace.GetEffectiveExecutionPolicy();
            if (policy != ExecutionPolicy.Unrestricted &&
                policy != ExecutionPolicy.RemoteSigned &&
                policy != ExecutionPolicy.Bypass)
            {
                ExecutionPolicy machinePolicy = runspace.GetExecutionPolicy(ExecutionPolicyScope.MachinePolicy);
                ExecutionPolicy userPolicy = runspace.GetExecutionPolicy(ExecutionPolicyScope.UserPolicy);
 
                if (machinePolicy == ExecutionPolicy.Undefined && userPolicy == ExecutionPolicy.Undefined)
                {
                    runspace.SetExecutionPolicy(ExecutionPolicy.RemoteSigned, ExecutionPolicyScope.Process);
                }
            }
        }

My question is whether the community thinks this would be ideal for PowerShell Tools for Visual Studio as well. Currently, PoshTools is behaving like the ISE rather than NuGet. What do you think? Leave a comment or shoot me an email.

PowerShell Tools for Visual Studio Beta v0.5

If you haven’t seen the news, PowerShell Tools for Visual Studio is now available on the Visual Studio Gallery! The first beta brings with it many enhancements from alphas past and supports VS2013 RC. Here’s a quick overview of  the current state of the extension.

Requirements

The current requirements for PoshTools are PowereShell v3 and Visual Studio 2012 or 2013RC. Several people have asked for VS2010 support and I’m researching the necessary changes. Also, there is a lot of interest in supporting VS2013 Isolated Shell. If the extension could be released in this manner it would make it completely free; just like the Python Tools for Visual Studio.

Editor Extensions

The extension adds language support to the Visual Studio editor. Some of the most important features are syntax highlighting, IntelliSense and code folding. IntelliSense with help you complete cmdlets and functions, variables and parameters. Code folding can collapse script blocks and comment blocks. Overall, syntax highlighting should be very similar to the ISE but there are known issues.

IntelliSense

In addition to the basic functionality described above, the extension also adds support for the function navigation drop down bars on the top of editors. Using the v3 AST PowerShell API, I was able to discover the functions defined within the current file and present the navigation bars seen at the top of the editor window.

Function Navigation Drop Down

A big next step for the editor is snippet support but extensions do not support this; making it a bit tricky to implement. If you have a particular function you’d like you see in the editor, head over to GitHub.

Debugger Extensions

On top of the big changes to the editor there have also been some big changes to the debugger. The goal was the surpass the ISE in terms of debugging functionality. To accomplish this, I added support for the locals, break point and call stack windows.

The locals window shows all the variables in the current scope and enables the user to expand complex objects to dig down into the object. Just like when debugging other .NET languages, type information is provided. Next on the plate for the locals window is the ability to modify values at runtime. In addition to locals window support, I’m also looking at adding Watch window support.

Locals Window

Another key window when debugging is the break point window. It displays all current pending breakpoints that are set within all the open projects. Like any other break point, the file name and line number are provided. There is no support for conditional break points but would be a good feature to add in the future.

Breakpoints Window

Another important debugging window that is supported by PoshTools is the Call Stack window. Using the Get-PSCallStack cmdlet, the extension can display the current call stack when stepping or breaking in the debugger. There is currently no support for moving call stack frames and interrogating session state.

Call Stack Window

Finally, like with PowerGUI VSX, there is a project system dedicated to PowerShell. It’s been discussed to add different types of project systems for modules or generic collections of scripts but this isn’t currently the case. The extension exposes a project system that recognizes PSM1, PSD1 and PS1 files. In the current beta there is no support for automatic signing or manifest creation. There are dialogs created for this purpose but the MSBuild tasks and targets aren’t yet hooked into the project system.

 

Project System

I’d love to hear feedback about the current status of the extension. If you are trying it out please leave a review on the Gallery or enter any issues on GitHub.

 

 

 

-->