misterhouse-users Mailing List for MisterHouse: Home Automation with Perl

It's interesting you say that, I've noticed a lot of things about HA I
don't love and am re-considering OpenHAB.

Same deal with my KeypadLinc's for fan control, I have a bunch of custom
code that turns the right buttons on and off when controlled externally so
the keypad always stays in sync with the state of the fanlinc itself.

When i'm all done I'll probbly add a wiki page for all of it. It does seem
like keeping all the complicated logic and Insteon specific stuff in MH is
the easiest at this point.


On Mon, Aug 11, 2025 at 1:42 PM <mis...@si...> wrote:

> On 8/11/25 10:15, Spencer Ryan wrote:
> > I've finally added more Insteon gear and after giving HA and OpenHAB a
> > run, nothing deals with Insteon as well as Misterhouse.
>
> Several of us are going to HA or OpenHAB for hardware control and MH for
> logic, with MQTT as the link. I'm using OpenHAB (having perceived
> philosophical/attitude differences with HA), but I haven't done much
> with OpenHAB and Insteon yet. Currently it's only managing my Z-wave
> stuff and random other devices it understands (e.g. SleepNumber bed,
> Denon amp).
>
> I'm really liking what I've seen over the last year plus, but migrating
> all my MH-based logic to OpenHab would be a huge project, thus the
> hybrid approach. This division of work is looking very viable, but when
> I look at transferring the Insteon devices over, I'll proceed with
> caution. Thanks for the alert.
>
>
>
>
> ________________________________________________________
> To unsubscribe from this list, go to:
> https://lists.sourceforge.net/lists/listinfo/misterhouse-users
>
>

On 8/11/25 10:15, Spencer Ryan wrote:
> I've finally added more Insteon gear and after giving HA and OpenHAB a 
> run, nothing deals with Insteon as well as Misterhouse.

Several of us are going to HA or OpenHAB for hardware control and MH for 
logic, with MQTT as the link. I'm using OpenHAB (having perceived 
philosophical/attitude differences with HA), but I haven't done much 
with OpenHAB and Insteon yet. Currently it's only managing my Z-wave 
stuff and random other devices it understands (e.g. SleepNumber bed, 
Denon amp).

I'm really liking what I've seen over the last year plus, but migrating 
all my MH-based logic to OpenHab would be a huge project, thus the 
hybrid approach. This division of work is looking very viable, but when 
I look at transferring the Insteon devices over, I'll proceed with 
caution. Thanks for the alert.

We bought a new house a few years ago right as Insteon was collapsing and I
kind of put a pause on what to load the new place with. I had misguided
high hopes for Matter device and still don't have anything that looks as
good as Insteon.

I've finally added more Insteon gear and after giving HA and OpenHAB a run,
nothing deals with Insteon as well as Misterhouse.


So I've started down the rabbit hole of making MH do everything insteon and
HA for modern creature comforts like HomeKit, etc.

HA has it's own quirks with Fans, specifically if you want a
off/low/med/high slider to show up you need to tell it the fan only has 4
states, but then the 0-100 range needs to be mapped to 0-3.

As I keep going down the hole it turns out the MQTT code in MH doesn't
support "FAN" as a type. I intend to build this in, eventually. For now
though I exposed the fan as a dimmable light, and deal with the unfun on
the HA side.

If this helps anyone at this point, I created the fan as a normal light,
with discoverable disabled, and then used MQTT Explorer to add the
autodiscover record by hand. Here's all the magic

{
  "unique_id": "insteon_51D36002",
  "name": "Master Bed Fan",
  "state_topic": "insteon/mbr_fan/state",
  "percentage_state_topic": "insteon/mbr_fan/state",
  "schema": "json",
  "command_topic": "insteon/mbr_fan/level",
  "percentage_command_topic": "insteon/mbr_fan/level",
  "platform": "fan",
  "state_value_template": "{{ value_json.state }}",
  "percentage_value_template": "{% if value_json.brightness == 100 %}3{%
elif value_json.brightness >= 50 and value_json.brightness <= 99 %}2{% elif
value_json.brightness >= 1 and value_json.brightness <= 49 %}1{% elif
value_json.brightness == 0 %}0{% endif %}",
  "command_template": "{ \"state\": \"{{ value }}\"}",
  "percentage_command_template": "{ \"state\":\"{% if value > 0 %}ON{% else
%}OFF{% endif %}\",\"brightness\":{% if value == 3 %}100{% elif value == 2
%}75{% elif value == 1 %}25{% elif value == 0 %}0{% endif %}}",
  "speed_range_max": "3"
}


I'm hoping to genericise most of that into the MH config where you'd be
able to define if you want a fan to act like a 4 speed fan or variable
(0-100%)

What was always a curious annoyance turned into a rabbit hole.

I noticed that on my FanLinc's when I would change the fan speed the
command was sent but the object in MH never got updated with the new
setting. Odd I thought but not a big deal.


Well I tried to write some automation around the fan speed changing and
none of the events would fire. This led me down the rabbit hole to discover
the code that deals with the ACK from a FanLinc was built incorrectly and
thus a Fan (Group 02) ACK would never be processed, which means MH would
never update the state of the object and thus no code that watched for it
to change would ever fire.


I fixed it.

https://github.com/hollie/misterhouse/issues/942