Advice - New home, fresh install via Docker, fresh start

I just recently moved into a new home. As the paint is starting to dry, I’ve started pondering the best way to go about setting up my new smart home. Unlike some people on here who are building from scratch, I largely have to work within the confines of what I’ve been given. However, I’m comfortable with electric work and plan on doing some remodeling anyways so I might coordinate running Cat6 along with new electrical cable to certain areas of my house.

I want to be intentional about good design choices as I build my openHAB installation, as I noted in the last house that I rarely fixed things once they were functional, even if they could be done in a much better way.

Coinciding with the move is a change to a new server setup. I used to run a two RPi3 setup - one Pi was setup with openHABian and served openHAB, Frontail, and NodeRed. A second RPi3 served Logitech Media Server and a Squeezebox along with Mosquitto. I decided to merge these systems to one Ubuntu based Docker setup. I’m also configuring Shinobi to run on this box. Using Docker is a bit of a learning curve though I have Frontail and openHAB running smoothly. Shinobi running (barely so far), and I’m planning to add Mosquitto, Grafana, NodeRed, and Logitech Media Server/Squeezebox.

I want to create a much better logical name system. Inspired in part by @rlkoshak, here’s part of my new groups items file:

/* Room Groups */

Group G_ENOR "North Exterior"
Group G_EWES "West Exterior"
Group G_EEAS "East Exterior"
Group G_ESOU "South Exterior"
Group G_EPTW "Play Tower"
Group G_EGBX "Garden Box"
Group G_EROF "Roof"

Group G_1UTI "Utility"
Group G_1OFC "Office"
Group G_1STO "Storage"
Group G_1UNA "Unassigned Room"

Group G_2GAR "Garage"
Group G_2COR "Lower Corridor"
Group G_2BR4 "Bedroom 4"
Group G_2BT2 "Bathroom 2"

/* Function groups */
Group G_HVAC_Thermostat "Thermostat"
Group G_HVAC_AtticFan "Attic Fan"

Group G_SFTY_Security
Group G_SFTY_Security_Motion
Group G_SFTY_Security_Contact
Group G_SFTY_Security_Contact_Interior
Group G_SFTY_Security_Contact_Exterior

/* model items */ 

Switch V_3SUN_ZW_Motion 	"Motion [MAP(]"	<motiona>		(G_3SUN, G_SFTY_Security_Motion, G_HIST)		
Number V_3SUN_ZW_Temp		"Temperature [%.1f °F]"         <temperature>	(G_3SUN, G_ENVS_Temp)			
Number V_3SUN_ZW_Humidity	"Humidity [%.0f %%]"	        <humidity>		(G_3SUN, G_ENVS_Humidity)						
Number V_3SUN_ZW_Luminance	"Luminance [%.0f Lux]"	        <dimmablelight> (G_3SUN, G_ENVS_Luminance)						
Number V_3SUN_ZW_UV			"UV"					        <sun>			(G_3SUN, G_ENVS_UV)						
Number V_3SUN_ZW_Battery	"Aeon Multi Battery [%s %%]"	<battery>       (G_3SUN, G_DIAG_Batt)	

Switch	A_2COR_PH_Switch	"Bloom Lamp"	                                (G_2COR, G_FUNC_Lights)	
Dimmer  A_2COR_PH_Dimmer	"Bloom Dimmer"	                                (G_2COR, G_FUNC_Lights)
Color 	A_2COR_PH_Color		"Bloom Color"		            <rgb>	        (G_2COR)		
Dimmer 	A_2COR_PH_ColorTemp	"Bloom Color Temperature"					    (G_2COR)
String	A_2COR_PH_Alert	    "Bloom Alert"                   <alarm>         (G_2COR)    
Switch	A_2COR_PH_Effect	"Bloom Effect"                  <colorwheel>    (G_2COR)

The idea behind my naming convention is that I can find it using VSCode’s autocomplete feature by location (ex. 2GAR), by function (SFTY for Safety, HVAC, etc.), or by connection (ZW, NS, MQ, etc.).

One question I have for the community - when deciding how to name your .items files, how do you separate them out? I used to use a separate file for each connection method or binding (i.e. mqtt.items, zwave.items, nest.items, etc.), but am considering both location (2BR4.items) and function (HVAC.items) and am curious if anyone else follows those conventions.

Starting over is a lot of work but I think the results will be worth it!

Functionally. This is less important for the .items files as it is for the .rules files. When you separate it out functionally then you are more likely to be able to share global vars, vals, and lambdas for rules that address the same function then you will if you use location or binding. So split your .rules by function then split your .items the same way to provide symmetry (i.e. you know the Items that are used in the lighting.rules file are likely defined in the lighting.items file).

I’m really against separating them by binding. For the most part it should not matter in your Rules (or sitemap or persistence) what bindings the Items are linked to. One of the main points of having Items is to provide a layer of abstraction between the physical devices and the logical meaning of those devices in your home automation. For example, instead of “Zwave_Node6_Switch” you have “Livingroom_Lamp”. The first one is pretty much meaningless, the second one tells you exactly what the Item represents. So given your naming pattern, I would drop the connection part of the name entirely. It really doesn’t provide meaningful information from a Rules or persistence perspective.

I’ve also found that having Groups for locations or put in the Item name to be more trouble then it is worth in most cases. For example, what room do I put the HVAC in? It is relevant to the whole house. Over time I found I had more exceptions to the naming rules than I did Items that followed the naming rules so I’ve reduced my naming conventions down to just the following:

  • If it is a Group make the name plural
  • It it is a value (e.g. sensor reading) prepend an ‘v’
  • If it is an actuator (e.g. causing something to happen) prepend an ‘a’
  • If it is a Expire binding Timer, use Design Pattern: Associated Items naming convention with “_Timer” appended
  • Make the names descriptive and meaningful

And the only reason I still use the v and a is because I have cases like the garage door opener that have both a sensor and an actuator.

I also organize my sitemap functionally instead of by room.

Remember, the organization of your files and the naming you choose is for YOUR benefit. The computer doesn’t care. So do what makes the most sense for how you work. This is what works for me.

Some other considerations on Item naming. One of the most useful DPs (IMHO) is Assocaite Items. Don’t chose a naming convention that makes this challenging.

Also, are you aware that for lights, you can send an ON/OFF or a PercentType to a Color Item? This means that you likely don’t need separate Switch and Dimmer Items for your Colors bulbs. Just put the Color Item on your sitemap as a Switch (to treat it as a Switch) or as a Slider (to treate it as a Dimmer).

As always, thanks for the advice.

I think I agree with you. I’m going to do functional definitions this time.

I see your point, and I think I’ll never nix the room groups. They are kinda pointless and lots of work to keep updated. I do think plan to keep rooom names in for non- global items, but am shooting for consistency for everything that doesn’t have a fixed room.

Yes, I did - I left these items in for HABpanel for instances where I didn’t want the full color options.