eTRV inputs (reqd temp and valve state) do not work

[ghost]

None of the entity inputs have any effect on the device, i.e. the following code:

input_number:
    lounge_temp:
      name: Lounge Temperature Target
      min: 10
      max: 23
      step: 1
      unit_of_measurement: "°C"
      mode: slider
      initial: 18
      icon: mdi:thermometer-lines

input_select:
    lounge_trv_state:
      name: Lounge TRV Valve State
      options:
        - Closed
        - Normal
        - Open

They are not mapped to the relevant mqtt topics:

    - platform: mqtt
      state_topic: "/energenie/eTRV/Command/ValveState/8008"
      name: "command_valvestate_8008"
    - platform: mqtt
      state_topic: "/energenie/eTRV/Command/Temperature/8008"
      name: "command_temperature_8008"

One fix Graham, could be to introduce automation, which I have tried and works, viz:

automation:
  - alias: Temp slider
    initial_state: true
    hide_entity: true
    trigger:
      platform: state
      entity_id: input_number.bedroom_temp
    action:
      service: mqtt.publish
      data_template:
        topic: '/energenie/eTRV/Command/Temperature/5460'
        retain: true
        payload: "{{ states('input_number.bedroom_temp') | int }}"

The input_select for valve state also needs similar automation , just tweak my code above.

Clearly bedroom_temp and 5460 need to be substituted with the user's appropriate confg.

Great work Graham and hopefully this can be fixed. I am finding your efforts really helpful.

[gpbenton]

I have an appdaemon app that detects changes to the ui and sends the appropriate mqtt commands.
Using HA automations would work as well.

[ghost]

Yes, i noted that on the wiki, I was merely helping out with the yaml. It will not work on its own, so I presumed you would want to update it, after all there's no benefit from maintaining an example that is on its own, is unusable? i know i wouldn't, id either update it or just remove it altogether.

[gpbenton]

I think you used the example in the way its intended. As a starting point to your own configuration. I have no intention of trying to keep an up to date working example for any of the controllers that might be used. Least of all HA, which changes far too frequently to be any fun to maintain.

However, if you are willing to publish and maintain your configuration, I am more than happy to link to that as an example.

[ghost]

i do. but on my own site. you're a strange chap graham

im a developer at baesystems, ada , c, c++, c#, java, sql, vb, assembler, html, css, fortran, pascal, python, node, tens more

never met such arrogance from a "developer" who posts and maintains codebases that simply, do not work. CRAP. what planet you're on, only you know... I'll leave you in youre bubble and god help you in what i can only presume is a lonely, sad, dull life with little love and appreciation from anyone.. that's the person you are

[gpbenton]

This project is not about supporting HA configurations, it is about writing a driver for the energenie board.

I'm sure one of the things you are aware of as a software developer is mission creep. As such, examples of its use are not part of the codebase, and I am not willing to make them part of it. That is the reason they are in the Wiki. As far as I can see, they have served their purpose in getting to you started, and that is all they are intended to do.

If you are willing to maintain an accurate codebase of an HA configuration on your own site, please send the link to me and I'll post it on the wiki, but I am not willing to spend the time doing that myself.

And please try and be civil. I am spending part of my weekend answering questions about your HA configuration, which I have no interest in. If my answers are terse, it is because of that.