Re: [mh] Where next with MisterHouse

My suggestions -

As mentioned recently I've been updating to Git, and not quite there 
yet, but I think given the type of thing MH is, and the types of users 
who would choose it over any of a multitude of other point'n'press App 
or other such solutions, these days working off Git with a local branch 
regularly updated from master is probably the most practical. I doubt 
"releases" fit the mould any more. Improving the docs on how to do this, 
how not to break it etc would be a better investment in time IMHO.  In a 
similar way, I used to maintain a CVS "vendor branch" back in the day 
and it worked OK.

UI. Much of my merge/update work in #Lockdown1 was on IA7. It needs a 
bit more work, but a huge amount has been done, and it works well, 
providing real state feedback for many of my items without much sweat.  
I have made some improvements to multi-state items (e.g. Squeezeplayers 
control/show states), added optional 1-click activation for on/off's 
that was sorely missing, and 1 or 2 other tweaks. I got stuck on the 
missing drop-downs that I use a fair bit in IA5, and that's when summer 
came round.  I vote for more work on top of the great IA7 contributions 
already made.

So it may be that a few items on your list have been hit. Many of my 
low-level implementations are around the venerable xPL, but same 
principles apply elsewhere, and I've only had to tweak here and there to 
get state feedback working.  I can even have a production and dev MH 
talk to the same xPL daemon and IA7 can read or track states. I'm not 
sure there's much or any core (Generic) functionality missing, maybe 
just the relevant interface code?

Getting more involvement? I think MH is a different market, anyone 
looking for a quick'n'dirty, non-integrated solution will have half a 
dozen apps, Alexas etc, and probably happy.  Making it easier for people 
to submit fixes and improvements to Git in a controlled way will 
gradually improve it and keep it alive, attracting those that want more 
integration, and support for newer hardware.

In terms of deprecation/health warnings - a log of each module's status 
would help, perhaps there's even a Git mechanism, I don't like killing 
things off because nobody has tested it recently, it may have useful 
code, and might even still work for those of us recycling last year's 
hardware.   The Linux wireless page is an example where they list each 
card type and link to a page with info. The kernel almost never kills 
off a module, the old soldiers just fade away.  Allowing the MH 
community users to contribute would be handy 
https://wireless.wiki.kernel.org/en/users/drivers. Similarly PCP used to 
provide a list of USB hardware with hints, which I found useful 
https://sites.google.com/site/picoreplayer/home/List-of-USB-DACs - and 
was able to contribute to.  It may appear "unstructured" but was a fount 
of useful info you could easily search.


On 4/01/2021 10: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.
>
> Here are some questions that you may have views on;
>
> Should we do another major release of what's currently in Master?
>
> Do we need a new web UI?
>
> How do we get more people to use and contribute to MisterHouse?
>
> 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.
>
> 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?
>
> If you have views/suggestions, please respond to this thread, if it 
> gets too cumbersome, I'll split it onto a number of individual threads.
>
> Stay safe
>
> Giles
>
>
>

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