Adding a functional button entity

[AlmostInteractive]

Hey @RobSmyth , I was hoping I might borrow some of your genius. I'd like to make a ButtonEntity but I'm a little lacking in experience. I added the entity description to the HassTypesGeneratorDefinition.cs file and while it shows up and the button works from HA -> App, two things are still wrong:

• I can't activate the button from the App (eg: App -> HA)
• Every time mqtt stops or starts it publishes /{button_name}/config which, for some reason, activates a button press in HA (the event description is: "{button name} changed to {date_time of event}")

Here's a link to my changes, insufficient as they are. Do you have any thoughts about how to resolve those issues?
https://github.com/AlmostInteractive/Net2HassMqtt/compare/main...AlmostInteractive:Net2HassMqtt:buttonEntity?expand=1

[AlmostInteractive]

I just found your TODOs: button and event. :) I have a use case for one or both! I'll bang my head against it for awhile but I'd sure like your input. I'm not sure I'm smart enough to do it alone.

[RobSmyth]

Yea, I have not done the button as it is an 'event' and I have not looked at how to do that. Nice you found the HassTypesGeneratorDefinition.cs.

I'll have a bit of a look and get back to you.

[AlmostInteractive]

I ran some experiments, evidently buttons get "pressed" (according to HA) whenever the state changes, so if it becomes Unknown or Unavailable then that will trigger a Button Press automation. :-/ Nothing I can do about that.

I've got an event being fired within the entity code, and it's publishing "something" to MQTT, but it's not the correct something. (I shoehorned in the entity stuff but it might give you an idea of what I'm thinking about.)

I created an event in my app like this:

device.HasEvent(config => config.OnModel(this)
            .WithEventProperty(Subscribe_TestButtonPressed, Unsubscribe_TestButtonPressed)
            .WithEventTypes(["press"])
            .WithFriendlyName("Test Event")
            .WithNodeId("test_event"));

...

public event EventProperty? TestButtonPressed;

    public void Fire_TestButtonPressed() {
        TestButtonPressed?.Invoke();
    }

    public void Subscribe_TestButtonPressed(EventProperty callback) {
        TestButtonPressed += callback;
    }
    
    public void Unsubscribe_TestButtonPressed(EventProperty callback) {
        TestButtonPressed -= callback;
    }

Currently, the Event doesn't register in HA because the {topic}/config is missing the event_types field. I'm trying to figure that out at the moment.

[RobSmyth]

@AlmostInteractive - I took at your PR. Nice! It makes me very happy to see that somebody can read my code and extend it. Thank you.

I took a look at a button I have on my MQTT network. The question that we need to resolve is - how doe the client app model events?

All of the entities to date are state entities. Something reports ON and in an hour if nothing is reported it is still ON. So the code tells the MQTT broker to retain this value. This means that if a client (HASS) is restarted it gets the current state. Events, I think, should not be retained as we do not want to be told the button is pressed every time HASS is restarted.

So there is the first, not so big issue - do not retain events.

In MQTT the events are otherwise pretty well the same as the states. When I press my button it will sent an event value of "single", "double", or "hold" (that I know of). After I release it, it seems to send an event value "" (empty string). So how does the model provide this?

If we use properties, as we have to date, then the application would need to do the work of setting a string property to "single" for say 100ms and then to "". It does not feel right. Hmm. I'm wondering if a public event would be the go. That is rather than adding a button property we add a button event on the class and listed to events ... that feel right. Doable but different to all the others :-)

So a model may look something like:

public class MyAppModel : ObservableObject
{
    public EventHandler<Net2HassEventEventArgs> ButtonPressedEvent;   // <<< entity will subscribe to this?

    [ObservableProperty]
    private bool _switch1 = true;    // a typical notifying state property the code uses now - no change
}

The bit I do not like is that is exposes a N2H data type Net2HassEventEventArgs in the client app (sigh).

I'm still pondering ... does this make any sense? Your thoughts?

[AlmostInteractive]

Happy to help, @RobSmyth ! :-) I also thought about temporarily setting a property and unsetting it, as you suggested, but I think that would result in two button presses and possibly two event triggers. The code I've got in there now is listening to an event for both Button and Event entities. It's a little hacky but it's working, I can see the event listener responding. At the moment it's calling EntityBase::OnEventActivated which publishes a command. That may work, but two things:

• No matter what I publish on MQTT, HA doesn't respond to a button message
• Event entities aren't showing up because they need event_types to be set on the {topic}/config and they're not, even if I put them into additional_options. I haven't been able to trace a path from additional_options to the EventConfigMqttJson constructor to set the EventTypes. Maybe you know a way?

[RobSmyth]

Sounds like we are both on the same wavelength. I'll give your code a run and get back to you.

[AlmostInteractive]

I fixed point 2 above. :) It's now correctly publishing the AdditionalOptions in the entity config! It's publishing on event detection, but I don't think it's publishing the correct information. I can't get it to trigger anything in HA.

I'm on the other side of the world so I'll catch you when I wake up.

[RobSmyth]

What I notice is that the publish payload just has "press". Look at the differences between battery_1_charging and test_event here seen in MQTT Explorer:

The configuration has:

  "value_template": "{{ value_json.state }}"

but no "state" property in the payload. The battery_1_charging looks like this:

{
  "data": {},
  "state": "ON"
}

[RobSmyth]

I do not know but I think you may want to send 2 events. "press" then "" or "None" as the press is a momentary event.

FYI - I capture button press events in Node-RED by an event:

[RobSmyth]

I think you want a payload like:

{
  "data": {},
  "action": "press"
}

data is used for attributes.

[AlmostInteractive]

I updated that branch to send that payload but it's still not registering in HA. I've been using MQTTX to manually send events over the network as well, and nothing I send to any topic I can think of registers as "Detected an Event" in HA. The only "events" detected are when my app starts up or shuts down (birth or lwt messages):

Also, I added you as a collaborate on that project in case you want to make contributions to my/your repo 😂

I think if we can figure out what message to send, then the Button will work. Once the Button works, getting the generic Event to work should be simple.

[AlmostInteractive]

Okay, so it seems to be working with hacommsclient/hacomms/test_event {"event_type": "press"}. The problem is the value_template in the config. When I remove it, it works! So we need to modify/remove the value_template for events (and maybe buttons, haven't experimented yet).

[AlmostInteractive]

End of day update: It works. I've got it so the value_template can be overridden via HassTypesGeneratorDefinitions. By setting the value template to null, the event works.

Right now it's hardcoded to send "press" but it shouldn't be too hard to make it a generic payload event with "event_type" being required. It kinda bugs me how I shoehorned in Subscribe/Unsubscribe but I'm not really sure how to change it.

[RobSmyth]

End of day update: It works.

Great to hear :-)

It kinda bugs me how I shoehorned in Subscribe/Unsubscribe but I'm not really sure how to change it.

Is this the subscribe/unsubscribe methods on the model?

[RobSmyth]

I've created a branch in your repo off your working branch.

I think the code needs refactoring to make way for easier event implementation. I'm removing base class between attributes and entities and renaming the EntityBase class to StateEntityBase class. The intent is be able to add an EventEntityBase type so there is clear separation ... see how it goes. I may abandon this ... see how it goes :-)

[AlmostInteractive]

Oh, I like that idea! I should have thought of that! Yes, okay, much better approach. Mine is the prototype to show that it can work, yours can be the elegant solution that goes to prod. 😂

[RobSmyth]

Excellent. That sounds great. :-)

[RobSmyth]

I see, I think are 3 different events?

That helps improve my understanding. Thx.

You can't trigger a button press via MQTT message

Wow ...that blows a lot of my thinking.

I need somebody hands on ... thank you. Big help. Nothing decided in my mind.

[RobSmyth]

Hows about:

CTRL + Play = { "event_type": "play", "value": "media_player.chromecast" }
CTRL + L = { "event_type": "toggle", "value": "LivingRoom" }
CTRL + M = { "event_type": "run_script", "value": "play_music"}

[AlmostInteractive]

Unless I dump JSON into "value", essentially turning it into a Dictionary, there'll be use cases that fall outside the "value": string format. For example, one I haven't written yet, might look for something like this:

{ "event_type": "run_script", "value": "play_music", "search": "Red Hot", "search_mode": "Artist", "playlist_type": "random"}
{ "event_type": "run_script", "value": "play_music", "search": "Red Hot", "search_mode": "All"}
{ "event_type": "run_script", "value": "play_music", "playlist_type": "random"}

With any number of variable combinations requiring a new configuration and class. I could, but I wouldn't; I'd implement a DictionaryEventArgs on the client side and use that. 😂

I could dump it all into JSON and shove that in "value" but that seems less user friendly. As long as I can get a key-value pair somewhere into the event to be parsed and sent along to HA, I'll be happy.

[RobSmyth]

My last post today, see ya.

Further brain storming...

public class HassEventArg
{
    public string Key { get; }

    public HassEventArg(string key)
    {
        Key = key;
    }
}

public class HassEventArgs : EventArgs
{
    public HassEventArgs(string eventType, params (string key, string jsonValue)[] args)
    {
        EventType = eventType;
        JsonKeyValuePairs =  args.ToDictionary(k => k.key, v => v.jsonValue);
    }

    /// <summary>
    /// Key value pairs that are essential event information. Does not include attributes.
    /// </summary>
    /// <remarks>
    /// Send in MQTT payload as:
    /// <code>
    /// {
    ///     event_type: &lt;EventType&gt;,
    ///     args: {
    ///         &lt;Key1&gt;: &lt;Value1&gt;,
    ///         &lt;Key2&gt;: &lt;Value2&gt;
    ///             :
    ///     },
    ///     data: {
    ///         -- Attributes key value pairs --
    ///     }
    /// }
    /// </code>
    /// </remarks>
    public string EventType { get; }

    /// <summary>
    /// The event payload. Excluding attributes which are handled separately.
    /// </summary>
    /// <remarks>
    /// Payload described in <see cref="EventType"/>.
    /// </remarks>
    public IDictionary<string, string> JsonKeyValuePairs { get; }
}

public class ExampleModel
{
    public event EventHandler<HassEventArgs> MyEvent;

    private void InternalMethod()
    {
        MyEvent(this, new HassEventArgs("run_script", 
                                        ("script_name", "play_music"), 
                                        ("search", "Red Hot"),          // Nice choice!!
                                        ("search_mode", "Artist"), 
                                        ("playlist_type", "random")));

        // -- OR - Same code, author's choice --

        MyEvent(this, new HassEventArgs("run_script",
                                        ("script_name", "play_music"),
                                        ("script_args", """
                                                        [
                                                           search: "Red Hot",
                                                           search_mode: "Artist",
                                                           playlist_type: "random",
                                                        ]
                                                        """)));
    }
}

[AlmostInteractive]

Looks fine. Questions from a tired coder:

1. What benefit does this have over supplying a Dictionary?
2. Does it have to be a JSON string? it seems like any string would work. "[" isn't valid JSON I think it'll go over the wire just fine.
3. MyEvent is still public so it didn't solve for the encapsulation/model-only control that you were hoping for earlier, right?

[RobSmyth]

Looks fine. Questions from a tired coder:

What benefit does this have over supplying a Dictionary?

Not a lot. I like that the user does not need to declare a dictionary.

Does it have to be a JSON string? it seems like any string would work. "[" isn't valid JSON I think it'll go over the wire just fine.

My intent was that the value could be any string or as JSON. The keys and values would be formatted as JSON anyway. JSON may be used to allow for common args parsing my HA via MQTT template member.

MyEvent is still public so it didn't solve for the encapsulation/model-only control that you were hoping for earlier, right?

Actually it does ... another class cannot invoke a class's public event. It is not a delegate or action. Try it, the code will not compile. An event can take whatever arguments you like. Even when an event is public it can only be fired by the owning class (the "publisher"). It solves encapsulation.

The configuration of valid event types moves to the N2H configuration code. Runtime can still assert a valid type.

[AlmostInteractive]

I did not know that. Thanks! I'll do a version with tuples instead of a dict and see how it feels.

On the note of encapsulation, I made the HaEvent private in the model class and am still able to access it via reflection. I just had to add a method on the model to allow the firing and now I think it's the best of both worlds. 😄

[AlmostInteractive]

I put a new version into my master branch that supports both tuples and dicts with a couple nice Fire overloads. Dictionaries feel more comfortable to me (cuz I'm old) and tuples are more comfy for you (cuz you're cool) and now we can use both. 😃

[AlmostInteractive]

I merged that branch into my main. We can do some refinements (such as the ones you proposed) before we PR it into your code.

I checked with HA to see if it could handle a kvp event payload and it worked, as expected.

hacommsclient/hacomms/test_event
{
  "event_type": "press",
  "param1": "value1"
}

triggered:

event_type: state_changed
data:
  entity_id: event.hacomms_test_event
  old_state:
    entity_id: event.hacomms_test_event
    state: "2024-07-27T17:26:11.245+00:00"
    attributes:
      event_types:
        - press
      event_type: press
      param1: value1
      friendly_name: HAcomms Test Event
    last_changed: "2024-07-27T17:26:11.245807+00:00"
    last_reported: "2024-07-27T17:26:11.245807+00:00"
    last_updated: "2024-07-27T17:26:11.245807+00:00"
    context:
      id: 01J3TKN11DSED6VYQPAJN9V7MR
      parent_id: null
      user_id: null
  new_state:
    entity_id: event.hacomms_test_event
    state: "2024-07-27T17:26:48.448+00:00"
    attributes:
      event_types:
        - press
      event_type: press
      param1: value1
      friendly_name: HAcomms Test Event
...

[RobSmyth]

Very nice & informative. So the event's state is the timestamp and the event type etc are passed as attributes.

I wonder if this means that N2H attributes (HasAttribute) would not apply.

Much I do not know here.

[AlmostInteractive]

I dunno! :-D We're both figuring this stuff out together.

[AlmostInteractive]

So I've got this version built into my app and I'm loving it. I hooked up the keyboard CTRL + MediaPlayPause to fire an HaEvent, handled it in an automation, and wired it up to my home speakers. 😄

Super happy with this!

[RobSmyth]

I wonder if you have used other parts of N2H. I want to get an idea of what bits have been used by somebody other than me.

[AlmostInteractive]

This is my first time using your library and I'm glad I could contribute something to it. Here's my usage, if you're curious:

https://github.com/AlmostInteractive/HAcomms/blob/master/HAcomms/Models/HAcommsModel.cs

[AlmostInteractive]

Hey @RobSmyth sorry I've been incommunicado. I just moved and was without power. It's a whole thing.

Anyway! What do you think about my current branch? It's been working great for me, except for one thing that isn't new to my code and I don't know yet how to get around. Events and Buttons get triggered when the application starts because they get updated. This results in a phantom activation of my Events and also on the Button handler app-side. I have an idea about making a "HaPulseEvent" which will set state and then set it back to "unknown" moments later which I think will help my use case. But anyway, do you feel it's ready to merge into your code base?

[RobSmyth]

Hi!

I've been working on automated versioning for N2H, and other projects, so I've not got back to looking at this. But yes, I do want to merge it into N2H. I'm not sure about how to do the event bit, so I propose you raise a PR to a feature branch off master and I can make what changes I like before merging to master. Does that sound good?

Having a look at the Events and Buttons triggering on start.

[AlmostInteractive]

Neat. 👍 I opened the PR. If you figure out the trigger-on-start thing, that would be cool, but I think it's an HA thing. I tested with my S3 Box3 running ESPHome and its buttons triggered at startup too. Doesn't mean there isn't a hack-around though. 😄

[RobSmyth]

On the triggering on start ... not sure I have the code, can you point me at some lines of how/why they get updated at start? I see FireKeyboardComboEvent in your code fragment but not how it is called.

[RobSmyth]

I just did a very quick test of removing that retain option. It did remove the retained flag from the event on the broker after I fired another event.

So that option is making the broker retain event state even though HASS does not expect it to.

[AlmostInteractive]

Strange, in MQTTX I don't see the retained flag set on any of my Event fires.

[RobSmyth]

I'm so confused ... I've found MQTTX has some strange behavior. Often it does not show the retain flag until you restart it :-)

Also ... the flag usually disappears on update. I'm no longer sure what is happening.

[RobSmyth]

I think I've not caught up to what you have found and were trying to tell me LOL 😄

Looking at HASS logs I do not see any event message on start=up. Only the "online" message. HASS is displaying the last event as a state .... aaagggh!

I found a couple post were people report that events are fired on HASS start-up and people have done workarounds.

Perhaps add a "None" event value and send that immediately after the real event. Ouch.

[AlmostInteractive]

I actually wrote exactly that, a "pulse" option on the even that would send an "unknown" state 100ms after the event. It helps with NodeRed flows because you can filter those out, but it doesn't help with HASS (without filtering) since it still counts as a state change.

https://github.com/AlmostInteractive/Net2HassMqtt/tree/pulseEvent

[RobSmyth]

Great! Merged, I'll sort out my versioning and get another early dev release out soon.

[RobSmyth]

Even if not related to your event on start issue ... I'm fixing the retain flag now. Moving from client to each event that supports retain.

[RobSmyth]

For what little it is worth I've attached my HASS logs that show real events "A" / "B" and then a shutdown and restart.

home-assistant_mqtt_2024-08-03T07-01-51.239Z.log

[RobSmyth]

Hi @AlmostInteractive,

I've updated the code the N2H button branch. If you would like to have a look the class QuickStartDemoModel gives you a quick idea of the direction I'm going.

Interesting ... I now understand that HASS is looking for the event_type property and adding all others as attributes. This results in 2 N2H attribute sources:

1. Attribute properties that N2H always reads when the event is being published.
2. Attributes that the user's application (client) code adds to the event. I now understand that these are event type specific.

These events are now merged into the message and sent the same as other messages.

I'm now making the event configurable as a pulse as a HASS workaround. WIP. Thinking that it will treat the first event type as the steady (or idle) state and always publish immediately after an event. I feel dirty doing a work around, but it is a configuration option :-).

[AlmostInteractive]

HassDeviceClassesSourceGenerator/FileGenerators/EntityDomainConfigMqttSourceFileGenerator.cs line 114 looks to have a typo: - instead of ~.

I like the HassEventArgsFactory 😄

[RobSmyth]

HassDeviceClassesSourceGenerator/FileGenerators/EntityDomainConfigMqttSourceFileGenerator.cs line 114 looks to have a typo: - instead of ~.

I like the HassEventArgsFactory 😄

The - is about line spacing. On consumes white space on button not line breaks, the other consumes lines.

[RobSmyth]

A little more work done:

Remove need to configure event types individually (WithEventTypes<-enum->()):

        device.HasEvent(config => config.OnModel(model)
                                        .WithEvent(nameof(QuickStartDemoModel.Event3))
                                        .WithEventTypes<Event3Types>()   ...

Now supports optional clear after each event (WithFirstEventTypeSentAfterEachEvent):

        device.HasEvent(config => config.OnModel(model)
                                        .WithEvent(nameof(QuickStartDemoModel.Event2))
                                        .WithEventTypes(["Clear", "PressedC", "PressedD"])
                                        .WithFirstEventTypeSentAfterEachEvent()  ...

Let me know if this does not look right to you.

Now I need to test it :-) ... handle events is Home Assistant :-)