Re: [mh] Where next with MisterHouse

On 1/4/2021 5:54 AM, Giles Godart-Brown wrote:
> There has been quite a bit of activity recently on the Forum and I was 
> wondering if we should plan what to do next.
> 
> Should we do another major release of what's currently in Master?

Is there anything different between "what's in master" and "a major 
release"?

We don't have the ability to test everything, or validate all the 
pieces, because everyone is running different components. I'd say the 
era of "releases" is over.

> Do we need a new web UI?

Given the amount of customization in my own web UI, a new UI would mean 
me having to recustomize everything. I wouldn't sink a lot of effort 
into it unless it was someone's passion. In that case, I'd suggest a new 
version of the UI that the end user can choose from.

> 
> How do we get more people to use and contribute to MisterHouse?

One suggestion here was to move the entire project over to a new 
programming language. I will recommend against that.

I'm reminded of another open source program I'm on that has, I think 
started "rewriting from scratch" about 6 times. Heck, my last company, 
with a team of paid developers has been trying the same thing with their 
product. And MH is a team in only the loosest sense of the word, with 
wildly different opinions on how things should work. Along the way 
people will get pissed off, and the community of people capable of 
writing the code will get smaller.

First, the community we have, knows the thing that we have. If somehow 
everything was rewritten, I'd still be stuck in a language I don't know. 
In short, I won't move.

MH can be a complicated environment with a lot of moving parts. I 
couldn't move until all "my" parts worked even were I so inclined, as a 
user of MH, to invest all that time in rebuilding everything from 
scratch. All of the "edge" modules would be dead forever; the few people 
using them would be screwed.

More importantly, rebuilding everything is a huge commitment, and the 
odds of it ever completing are poor. Much of the base now (as above) 
won't know whatever new environment. Not everything would migrate - much 
of the modules require the specific hardware to test, which means 
someone has to: have the hardware, be motivated to move, have time to 
move, and know the language to move.

In short, it sounds cool, but if the identical amount of effort was 
poured into what's there NOW, the end result is a wildly better product. 
Or (more likely) a lot less works still ends up with a better product.

So my suggestion is to extend the MH code to support those thing 
specifically inside (as close as possible) to the current model.  If it 
won't work directly inside the current module, then make the extension 
modular, so it can be added on for those who want the functionality.

> Is there anything we should deprecate or provide with a health warning?  
> Going through the docs and ./lib files, there are a lot of modules for 
> redundant kit which is unlikely to be developed further (or even fixed) 
> and is often not documented fully.

Even if it doesn't work, it can usually be made to work by someone 
motivated (that being primarily where my own meager contributions come in).

In many respects, much of the MH code doesn't work due to changes since 
it was written (like USGS changing their file format). But someone out 
there has fixed it at a person level, and asking on the list can get 
those issues resolves, and improve the code.

> There has been a big change recently with cheap bi-directional Wi-Fi 
> devices and MisterHouse wasn't really created with this in mind, notably 
> we don't have a defined feedback mechanism to check that when we change 
> an item state this actually happens and we don't have a defined way of 
> having an item with multiple states (perhaps we should encourage JSON 
> for this), or multiple triggers (mqtt poses this question). I believe 
> the industry is moving further in this direction, Tasmota wont be the 
> last and only solution, so this begs the question;
> 
> Do we need some architecture changes to support bi-directional devices 
> with feedback?

This state confuses me, as I'd swear somewhere there's the code to check 
on the status of a device. I don't use it (X10 not being renowned for 
it's ability to tell you what's going on), but I at least remember one 
of you wizards talking about it?

Backwards compatibility is everything to me.  I have code that's still 
running from 2008 in hardware of that same era. So adding that support 
ideally means having me be able to drop it into my code.


One HUGE advantage of how MH is written is the ability to add or 
customize code. One huge disadvantage is really the same thing, because 
once something is customized, who wants to do it again?

Rick



> Giles
> 
> 
> 
> 
> 
> ________________________________________________________
> To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users
> 

-- 
Rick Steeves
https://www.irelandbybicycle.com

It's all fun and games until someone ends up wearing a cone.


________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users