New to Home Automation Looking for a Single app?

[PerH]

I run Grafana on a windows machine now. It works, but is a bit fiddly as it is at beta stage..

[PerH]

Does anyone here use an alternative to imperihome? the Imperihome bridge doesnt transfer all sensors for some reason.. motion sensors, light sensors, UV doesnt come over..

I want a status panel, but I want to be able to set i.e light schemes, open the garagedoor, etc from these panels.. (Old tab's and phones in 3d printed frames)

[PerH]

I've been looking at Home Remote, but it seems to need to connect to the vera servers for credentials, and I can't find another way to connect in openluup..

[ArcherS]

@perh Take a look at Homewave if you are on iOS. It works with Vera, both UI5 and UI7 and it also works for OpenLuup. You can have multiple controllers mapped seamlessly at the same time.
For Veras it works with cellular access, for OpenLuup you need a vpn to access the system when being off-site.

//ArcherS

[Black Cat]

There is other visualisation software that will do what you want, but it comes with a high price tag...
Possibly the best professional system, IMHO is Eisbaur Scada (google is your friend), there are other professional systems available, it all comes down to price or user familiarity.

[PerH]

Only one iOS device in the house, and its not mine!

I want this to go local communication only, I just use altUI (via dataplicity) when i'm not home.. This is mainly for some UI pads i plan to have around the house, all android..

[therealdb]

@perh I ended with my own solution.

I searched a lot, but I couldn’t really find something ready. It’s obviously not generic, but I have thermostats, a/c, sensors and much more. It’s running on fully kiosk in fire tablets, that I control via mqtt/api, so I can display cams after motion events and much more.

[toggledbits]

I've also rolled my own. It will be included for optional use with the new multi-system Reactor.

[cubs2b23]

Today I tried to use Fully Kiosk on an old Samsung tablet but the AltUI wouldn’t fully loaded. But it would load fine in the regular Chrome app

[Black Cat]

@toggledbits said in Status Board - What’s your HA Information Dashboard ?:

I've also rolled my own. It will be included for optional use with the new multi-system Reactor.

Missed this.......tell us more.......

[toggledbits]

@black-cat It's a skinnable tile interface that maps properties/capabilities to display controls (widgets). Each widget supports multiple canned layouts, and you can do custom layouts (either as per-device exceptions or globally-available). Widgets are tiled and moveable/sizeable. They are mapped to device properties and you can use expressions to fetch values, map values, etc. For example, the scene widget can be "active" based on the state of any device state or expression, not just the "active flag" on the scene itself--that is, a widget is not limited to sourcing data from one device/thing. So, for example, the thermostat widget can draw current temperature from an in-room multi-sensor, and on-off heating control by a plug-in switch, etc. Basically, instead of having to make a virtual device to collect data to a single object that is then displayed by a canned-appearance widget following rules particular to that device type, the widget just brings all the data together from whatever sources and displays it; actions work the same. If you want your thermostat in the bedroom to display the outdoor temperature in Moscow, you can do it. Easily. If you want a "binary sensor" widget to show tripped/alarm state when the pool pump is running after sunset, no problem. And you can do fun but sensible/expected things like when you activate a scene via a widget, the widget changes to the counter-scene (e.g. when you tap "Kitchen On" the lights come on and the widget then changes to "Kitchen Off"). Colors, fonts, sizes, etc. are all configurate/replaceable (CSS, HTML).

I've used and evolved this dashboard for years in my own home. It actually came into being first in 2017 when I made my first move away from Vera toward HomeAssistant (didn't happen, but that's another story). It was for family use, so right from the start, my idea was that nobody needs to know or care which controller is managing a device. Its hardware abstraction layer served as the launching point for a multi-system Reactor; I'll call it "MSR" here for brevity's sake. This MSR will work in a similar way: knowing the attributes and capabilities of a device, you can create rules using those, and rules that incorporate this data from multiple sources. That is, if your bedroom temperature is controlled by a space heater on a Tasmota-based relay board using control logic driven by input from a ZWay+openLuup-connected multi-sensor's temperature measurement, no problem. You configure any number of "controllers"; each instance announces what devices it has in inventory, and what attributes and capabilities they have. A controller can be an interface to Vera/openLuup, or Hass, or Hubitat, or just an HTTP-based element that fetches weather from OpenWeatherMap, or an interface to your EVL3/4-connect alarm panel, etc. It is an interface that simply says "these are the objects I have and this is what they know and do". So any device could be supported by a plugin in your Vera/openLuup/Hass/HE/other HA controller, or it could come from a dedicated controller crafted just for that device. For example, it currently supports Sonos through the Vera/openLuup plugin, but I (or someone) could write a dedicated Sonos controller that talks directly to the Sonos zones on the network and bypasses the plugin, maybe even uses their new API rather than UPnP. Controllers have a strictly defined behavior/contract, with the intention that others can develop controllers as well. This aspect is making MSR grow legs, a bit... it's really turning into a home automation controller all on its own. I foresee an ecosystem of available add-on controllers for every manner of device in future. This gives you the flexibility to determine what best supports the products you use; for example, if support for a particular Fibaro or Zooz device in Vera/eZLO is lacking/buggy (no--say it's not so!), you can instead include it on your openLuup+ZWay, Hass, or HE controller where the support is better, and MSR can find it there. But when creating your rules and activities, you don't have to know or care where that device lives. To the maximum extent possible, I am also keeping an architecture and implementation in which system objects (devices, groups, scenes, etc.) are entirely overridable and creatable through configuration. If you have a device type on Vera/openLuup that MSR doesn't natively support, you should be able to just go to configuration and say "this device type, or even this specific device, has these capabilities and these attributes". If a capability doesn't exist, you can create it locally immediately. Up and running in five minutes or less (modulo the first-time learning curve, of course). And for all of this, you should be able to contribute the configuration to the community if you wish (or find configurations/capabilities others have done and apply them). And of course, whatever to create/train is available both in the Reactor part and the Dashboard part.

I've focused mostly on the rules and reactions part of MSR for several weeks, and it lives and breathes now. Although algorithmically it shares ideas with Vera/openLuup Reactor, it is an entirely new code base (and not Lua). Huge strides have been made quickly, but of course, there are a lot of "TBD" comments in the code, and I'm sure no shortage of crashes in boundary conditions from things like unfinished input validation and so on. It needs combing out, some deep code reviews (which I prefer to do on paper), and backporting of some evolution of the evolved hardware abstraction to the Dashboard. There's plenty to do. But, with the freedom of creating the environment rather than working in someone else's, it's much faster and easier, and I'm really pleased with acceleration towards something usable over the last month. I'm about ready to cut over my own home's automations to it. There is nothing like the pressure of pleasing my "driving coach" to make sure I get things working well, and quickly.

[ArcherS]

@toggledbits Wow, sounds really exciting!
Today I use Homewave on my iPhone and on iPad, this sounds like the next step up towards a real dashboard.

//ArcherS

[toggledbits]

I don't really intend the Dashboard to be a do-all-end-all, but I think it will serve a large number of users adequately, and the entire ecosystem will provide an API and tools from which other dashboards could be built. I know some people don't like tiled interfaces. For me, it was just an easy choice and my family "gets it."

[Black Cat]

@toggledbits Thanks for the in depth reply Patrick, it's much appreciated and wets the whistle.

You didn't mention on what type of machine this will run on, Windows/ Lynx or ???

I have noticed over the past 6 months is the overabundance of new WiFi devices being released each with their own App.

Every manufacturer now has their own device with their own App- (I don't like cloud based solutions either) but they are not going to go away, so we are stuck with them whether we like it or not.
If it's within the realms of possibility to control these Apps from MSR as well then you've found the Holy Grail.

[toggledbits]

@black-cat The system will run on Windows, Mac, and Linux today. I haven't gotten to hardware requirements, yet, but RPis, NUCS, and small NAS systems are every bit as much targets for me as modest VMs or desktops. I will miss a big goal of my own if it isn't crisp on a wide range of hardware. I'm trying to get through all the "just get something working" level of UI shimming so I can do a preview/demo video. I've gotten used to UI7 with 180+ devices, and even for me, it's a bit shocking to see the difference in performance between my dashboard and theirs.

The concept of a "controller" in MSR is simply a management object that can publish entities (devices, groups, scripts/scenes, etc.). This is done by implementing subclasses of a Controller class. That base class, its contract, and associated utilities make a framework that's pretty well-defined and does a lot of the work that, for example, you'd have to do manually in a Vera plugin. But it's built to take data from any source and turn it into a controller object or set of objects.

[Matohl]

@toggledbits Interesting, when you are ready for Alfa or Beta I am ready to test it out.