SmartThings Smart Home Dashboard #8

In the previous post (SmartThings Smart Home Dashboard #7), we achieved our first fully-functional version of the Smart Home Dashboard (SHD). It was a long journey, but I wanted to try to walk through the key steps and concepts needed to get there. Make sure you refer to that post if you haven’t been following along. It will give you the information you need to get everything up and running.

In this post we are adding support for multiple locations. If your account is associated with multiple locations and you want to install the Smart Home Dashboard (SHD) at more than one location, you’ll want these changes. It will also give you the ability to get a “Combined” view that will show you all locations at the same time.

We’re also adding the ability to see all “Active” devices in one view. This will pull all active (on, unlocked, open, active, heating, cooling, and away) devices as well as devices that need attention, such as offline and low-battery devices, across a location into a single view so you don’t have to open each room to see exactly what is going on. This view will automatically update as the status of devices change. If you’re using a Combined view, it will show all active devices at all locations. All devices within this view are actionable, just like they are in the Room view. But if, for example, you turn a switch off while in the “Active” view, it will disappear because it will no longer be “active”, unless it still meets one of the other requirements, such as low battery.

Just to give a brief overview of the multi-location update, we will now require that our non-Admin users be associated with one or more locations (done using the Admin Console – Maintain Users page). Admin users will automatically have access to all locations. Once logged into the SHD, the user can click on their name on the top left of the page to get access to the other locations they have been granted. They will be listed right above the Logout option. When they select a different location, the screen will immediately refresh to show that new location. They can also choose Combined and all locations will be displayed in a single view. This combined view is applied across all SHD views, except when selecting a room.

To add support for multiple locations, we added a new user_locations table to our users.db database and added a new one-to-many relationship between the user and user_locations. We also had to start tracking sessions so we could support the same user being logged in on multiple devices and potentially different locations on each device. We set the user’s current location on the table to the last location they connected to (web socket connection, not login). That was simply designed to default to the user’s preferred location if they have multiple.

One hurdle we had to try to overcome was that guest users at another physical location obviously can’t be connected to the local network where your server is located. They will need to connect through your public URL. So I’ve removed the LOCAL_NETWORK_IP list check and created a new smartthings.db table (location_network) to store the IP address(es) for each specific location. These values are set in the Admin Console under the Rooms menu (Rooms Configuration). These are the IPV4 IP addresses from the perspective of the server and you can add any IP that you want guest users to be able to access that location from.

You can turn on user logging in the Admin Console -> Users -> User Logging page for either Login or Connect events to capture the IP of users at a given location so you can update the list. Some ISP’s don’t assign static IP addresses, so you may have to update it each time you have a new guest user, but hopefully it won’t be an issue. I’ve also added the ability to accept ALL IP addresses for a location. That will allow your guest user to access the SHD from anywhere, but they will still have the same restrictions for access to rooms, devices, and scenes as they did before.

Note: This currently only supports IPV4 IP addresses. If you use IPV6 IP addresses, you’ll have to select Allow Any IP Address for guest users to work.

In smartthings.py, we created a new class, SmartThingsController. This class will store an array of SmartThings objects, one for each location, and will allow us to access the appropriate object by location_id (i.e., st = stc.getByLocation(location_id)).

Our server creates a SmartThingsController object which, when initialized, loads all locations where our SHD is installed and then creates a SmartThings object and calls its initialize method for each location.

As events occur, they are sent to the appropriate SmartThings object within the Controller to be updated and then web socket events are emitted to all users connected to that location so they receive the real-time updates.

Admin Panel Updates

Added the ability to change locations on each page so you can easily make location-specific changes (Rooms, Presence, and Scenes). Note that this ability is on all Admin pages. Even those pages that are not location-specific, such as the pages under the Users menu.

Admin Home Page – The selected location determines which SmartThings data is refreshed when the Refresh… button is pressed.

Admin Home Page

Maintain Users – Added a Locations column. Click the cell to edit a user’s location(s). If a non-Admin user has no location assigned, they won’t be able to login. Admin users automatically get access to all locations.

View Active Sessions – Added a new Users menu item to allow you to see all currently active users and which location(s) they are viewing. These are active web socket connections, so they will come and go as the sockets are connected/disconnected. These are the sessions used by the server to make sure users are placed in the correct rooms and to process any commands they send to the server, such as turn on a switch.

Note: Admin users accessing the Admin Console pages don’t use web sockets or sessions. So you won’t see them listed in this display if they navigate directly to the URL.

Viewing active user sessions

Rooms Configuration – As noted above, a new Location Local Network setting was added to replace the LOCAL_NETWORK_IP list from our previous post. This allows you to identify any IPV4 addresses that you want guest users to be able to access that location from. You can choose the local network for the location where your server is located (i.e., “192.168.2.“), or the public IP address for a remote location (i.e., “123.45.67.”), or any combination of IPs, including the setting for Allow Any IP Address if you want guest users to be able to access that location from anywhere.

Note this only supports IPV4 addresses and that you only have to provide the network identity, or first three parts, of the IP address. You can enter all four parts, but only the first three parts will be save.d The fourth part is the specific host or computer identifier.

Here’s the updated code…

I’m moving all the code to GitHub so you don’t have to copy/paste from this post. Here’s a summary of the major changes by module in case you’re interested.

smartthings.py

Here we added a new SmartThingsController class to group and manage our SmartThings objects and, as a before, our SmartThings class manages all rooms/devices/scenes, etc. for a given location.

st_webhook.py

This is our Flask server. Some highlights of the changes made to support multiple locations include: Adding a user_locations table (UserLocations class) to replace our LOCAL_NETWORK_ID list with a one-to-many relationship with the users table (User class); Added a new user_sessions list to track all connected sessions, users and locations so we can validate the user/location relationship and emit updates properly to each session. Our @socketio.on(‘set-session’) event handler can reestablish sessions for users that temporarily lose their web socket connections; Added a new @socketio.on(‘location-change’) event handler for user requests to change their current SHD location; Added a new ‘/admin-view-sessions’ route so allow Admin users to view currently connected sessions in the Admin Console under the Users menu; Plus various other changes to derive user/session/location as needed.

dashboard.html

Here we added the list of available locations to the user menu, as well as a ‘Combined’ option if they have more than one. We also keep track of the location(s) being viewed so we can request them again if we lose the socket connection and need to reestablish the connection. When in a combined view, we also build and present a multi-location display for each menu view. When selecting a Room while in a combined view, the location name for the Room will also be displayed in case each the room name exists at more than one location.

admin_base.html

We added the ability for the Admin user to quickly change the location within all of the Admin pages. Although you can change the location on any page, it has no affect on the data displayed on pages under the Users menu, as those aren’t location-specific.

admin_users.html

Although the display isn’t impacted by changing the location, you do need to assign a location(s) to all non-Admin users (by clicking in the Locations cell for that user). They won’t be able to login until they are associated with at least one location. You can have User-1 that only has access to Location-A, User-2 that only has access to Location-B, and User-3 that has access to both locations, for example. Admin users will automatically have access to all locations. This data is written to the new user_locations table in the users.db database.

admin_sessions.html

This is a new page under the Users menu. It will allow Admin users to see all active sessions (web socket connections) and the locations that are being viewed by that session/user. These are the sessions that are used by the server to keep track of all connections.

admin_rooms.html

We added a new Location Local Network field to all the Admin user to define which IPV4 IP address can be used to access that location for Guest users. This data gets written to the new location_network table in the smartthings.db database.

Summary

Your SmartThings Smart Home Dashboard now fully supports multiple locations! I hope it works well for you and you find it useful!

Please let me know if you try it or if you have any questions.

What’s Next?

I need to do some research before I determine next steps for this project. I want to add some support for custom rules that I want that SmartThings doesn’t current support and I want to add weather information to the SHD.

The specific rule I want to handle right now is when the Bathroom Fan is turned on, capture the current time and humidity level. Run for a minimum amount of time and then begin checking the humidity level. Once the humidity drops below a threshold (i.e., starting level + 5%), then turn the fan off.

For the weather information, I need to determine if my current custom DTH can be used by others. If so, then I’ll include that as part of this project.

Leave a Comment

Your email address will not be published. Required fields are marked *