MQTT

[scudderfish]

I think MQTT is the key to this. I set up my own broker, fudged DNS so my shower thought it was aqualisa and I got a lot of traffic (> 1 message per second) from the shower. At this point nothing is flowing from my network to the cloud servers. I then tried and failed to turn the shower on with the app. What I think happens is the app makes a REST call to a cloud server, which then sends the instruction to turn on/off etc via the MQTT broker. This makes sense (to me) as it doesn't need to make an incoming call into the shower, the shower is just subscribed to some command topic and does what it is told to do.

My next plan is to figure out an MQTT SSL proxy so I can see whatever is sent back over MQTT from the cloud.

[peterchs]

Quartz touch. Purchased/installed a couple of months ago. Same error for me on the mosquitto side.

[cr3ative]

Oh that's very curious. Have you tried issuing fresh certificates for aqualisa-mqtt-[REDACTED].like.st ?

[rodgers86]

I’ve not! It’s all a bit of a learning curve, so I’m going to look into how I do that next!

I assume certificates references the server name then, which is why the posted certificates on GitHub won’t work with this one?

On Mon, 4 Sep 2023 at 10:27, Paul Curry @.***> wrote:

Oh that's very curious. Have you tried issuing fresh certificates for aqualisa-mqtt-ringfence.like.st ?

— Reply to this email directly, view it on GitHub https://github.com/cr3ative/homebridge-aqualisa/issues/10#issuecomment-1704924110, or unsubscribe https://github.com/notifications/unsubscribe-auth/BAXQQNMCBBKJR4MMLOAJ7FTXYWNGTANCNFSM6AAAAAAVQGAKTI . You are receiving this because you commented.Message ID: @.***>

[cr3ative]

I assume certificates references the server name then, which is why the posted certificates on GitHub won’t work with this one?

That's my guess - you're the first to point out this new server name, and it makes sense that it would be rejected. We can only hope they haven't also introduced anything smart like certificate validation/pinning during this change.

[jymbob]

given the failing one has the lower version number, is it possible to update it by selecting "Firmware update" from the settings menu?

[rodgers86]

I’m not actually convinced the Rev-build means anything.

I got a new control unit from warranty last week. It has 05-64922. I tried this unit too instead of the one that’s not working properly and it doesn’t work either. Both try to talk to the other server

The brains are all in the pink pump box in the loft. As it’s still connected to Wi-Fi and still attempting to talk to the broker even when the control is disconnected.

I did try to update. The screen goes orange, and then eventually just goes black, and you have to assume it’s done. But the Rev-build never seems to change.

Both work “okay” in the app, when the DNS is not diverted.

Have to say, they are good showers, but the “smart” functions are oversold and unreliable. So would be ideal if this would work.

On Mon, 4 Sep 2023 at 18:36, jymbob @.***> wrote:

given the failing one has the lower version number, is it possible to update it by selecting "Firmware update" from the settings menu?

— Reply to this email directly, view it on GitHub https://github.com/cr3ative/homebridge-aqualisa/issues/10#issuecomment-1705569336, or unsubscribe https://github.com/notifications/unsubscribe-auth/BAXQQNJ5FXHQKPIWNLJ4B73XYYGS3ANCNFSM6AAAAAAVQGAKTI . You are receiving this because you commented.Message ID: @.***>

[rodgers86]

So...

I've created new certificates. One with the server name as the IP of the MQTT broker. This resulted in the same error as before.

1693900854: New connection from 192.168.4.31:49307 on port 8883. 1693900854: OpenSSL Error[0]: error:0A000412:SSL routines::sslv3 alert bad certificate 1693900854: Client disconnected: Protocol error.

The other shower still works.

Then I tried again with the server name being equalise-mqtt-[REDACTED].like.st Now I get a different error

1693902290: New connection from 192.168.4.31:61966 on port 8883. 1693902290: OpenSSL Error[0]: error:0A000418:SSL routines::tlsv1 alert unknown ca 1693902290: Client disconnected: Protocol error.

The other shower still works.

[cr3ative]

So...

I've created new certificates. One with the server name as the IP of the MQTT broker. This resulted in the same error as before.

1693900854: New connection from 192.168.4.31:49307 on port 8883. 1693900854: OpenSSL Error[0]: error:0A000412:SSL routines::sslv3 alert bad certificate 1693900854: Client disconnected: Protocol error.

The other shower still works.

Then I tried again with the server name being equalise-mqtt-[REDACTED].like.st Now I get a different error

1693902290: New connection from 192.168.4.31:61966 on port 8883. 1693902290: OpenSSL Error[0]: error:0A000418:SSL routines::tlsv1 alert unknown ca 1693902290: Client disconnected: Protocol error.

The other shower still works.

I think this is a local error, with your broker rejecting the new certificates. Might be worth trying again, maybe trusting your self-issued CA on the broker machine, or perhaps there's a broken chain of trust. If this was the shower rejecting the certificate you made, I don't think it would send such a verbose rejection. But these are only guesses.

It might be worth trying to generate new certificates for the working shower (on the old hostname) and seeing if that works. If it does, you know at least that your method of generating certificates is working. You can then try the new shower and hostname from there.

[cr3ative]

OH NO

edit: I have sent a responsible disclosure to Aqualisa about this misconfigured server. I am going to redact the host name of the affected server from this thread out of an abundance of caution.

[peterchs]

Thats not good - another reason to make sure to not use the aqualisa servers and use a local broker.

Prompted by this latest debacle I tried again to onboard my shower to the app as they seem to be changing things. It worked (to the original mqtt server).

I was then able to use original mosquitto I had been testing with and it worked fine. I've got the shower starting/stopping through nodered no problem.

I suspect the previous client certs they were providing my shower during app onboarding were not encrypted correctly/broken in some way causing the shower to fail to connect to any mqtt server. Either that or there was a OTA update to my shower? (hopefully not or we could lose local mqtt in future)

Anyway - if anyone was having problems with shower being on wifi ok, not onboarded on app, and mqtt wasnt working - try onboarding on the app again it'll probably work and after onboarding you shouldnt have any problems connecting to a local mqtt broker if you follow the instructions.

[rodgers86]

They are relaunching the app apparently in summer. I emailed asking a few questions about why both showers had different Rev-builds and how do I know if a firmware update is successful. But never got the answer to those. But they did confirm they are relaunching the app to fix all the current issues.

What that means for this, who knows.

I’ve not tried again with my rogue shower yet. And won’t be for a bit. as I’m on holiday now for a week. But the fact that I could access everyone else’s shower gives me hope that I’ll be able to connect to mine locally with some more attempts!

I’m going to try unpairing and repairing in a new account on the app etc.

[scudderfish]

I'm concerned that you could see other showers. What broker were you looking at to see that?

On Thu, 7 Sept 2023, 10:50 rodgers86, @.***> wrote:

They are relaunching the app apparently in summer. I emailed asking a few questions about why both showers had different Rev-builds and how do I know if a firmware update is successful. But never got the answer to those. But they did confirm they are relaunching the app to fix all the current issues.

What that means for this, who knows.

I’ve not tried again with my rogue shower yet. And won’t be for a bit. as I’m on holiday now for a week. But the fact that I could access everyone else’s shower gives me hope that I’ll be able to connect to mine locally with some more attempts!

I’m going to try unpairing and repairing in a new account on the app etc.

— Reply to this email directly, view it on GitHub https://github.com/cr3ative/homebridge-aqualisa/issues/10#issuecomment-1709854187, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEF5PJJ2VKVH3KRLWDSHG3XZGKHPANCNFSM6AAAAAAVQGAKTI . You are receiving this because you were mentioned.Message ID: @.***>

[cr3ative]

@scudderfish I've deliberately redacted the broker name from this thread and disclosed the issue to Aqualisa, who have responded and are looking in to it.

It is not the original hostname, it's one newer hardware is connecting to apparently.

[rodgers86]

I can’t actually remember if it was the original one or the new one.

But basically my DNS forward obviously didn’t work momentarily but it allowed me to connect on 8883.

It’s not happened again, but concerning that it did.

On Thu, 7 Sep 2023 at 13:28, Dave Smith @.***> wrote:

I'm concerned that you could see other showers. What broker were you looking at to see that?

On Thu, 7 Sept 2023, 10:50 rodgers86, @.***> wrote:

They are relaunching the app apparently in summer. I emailed asking a few questions about why both showers had different Rev-builds and how do I know if a firmware update is successful. But never got the answer to those. But they did confirm they are relaunching the app to fix all the current issues.

What that means for this, who knows.

I’ve not tried again with my rogue shower yet. And won’t be for a bit. as I’m on holiday now for a week. But the fact that I could access everyone else’s shower gives me hope that I’ll be able to connect to mine locally with some more attempts!

I’m going to try unpairing and repairing in a new account on the app etc.

— Reply to this email directly, view it on GitHub < https://github.com/cr3ative/homebridge-aqualisa/issues/10#issuecomment-1709854187>,

or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAEF5PJJ2VKVH3KRLWDSHG3XZGKHPANCNFSM6AAAAAAVQGAKTI>

. You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/cr3ative/homebridge-aqualisa/issues/10#issuecomment-1710063186, or unsubscribe https://github.com/notifications/unsubscribe-auth/BAXQQNLIUN3DGKUP3ZNM6VTXZG4XDANCNFSM6AAAAAAVQGAKTI . You are receiving this because you commented.Message ID: @.***>

[scudderfish]

Phew! It makes me glad that my shower is not connected to their wide open infrastructure for some bored person to play with it for shits & giggles.

On Thu, 7 Sept 2023 at 13:31, Paul Curry @.***> wrote:

@scudderfish https://github.com/scudderfish I've deliberately redacted the broker name from this thread and disclosed the issue to Aqualisa, who have responded and are looking in to it.

It is not the original hostname, it's one newer hardware is connecting to apparently.

— Reply to this email directly, view it on GitHub https://github.com/cr3ative/homebridge-aqualisa/issues/10#issuecomment-1710071368, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEF5PIPNTCJZU6NMBE7DCDXZG5C7ANCNFSM6AAAAAAVQGAKTI . You are receiving this because you were mentioned.Message ID: @.***>

[paulandrewcrouch]

I’m reading this all with interest. I majored in cryptography when I was at uni, I mentioned to this to my old professor and specifically said “in theory, someone could control all the showers on the server….”. Impressive work and well done for the ethical bit of reporting etc.

On more mundane matters, 1st shower still works perfectly on Home Assistant with MQTT sent directly with a local DNS lookup on like.st.

2nd shower installed yesterday, I could get the app to connect to the shower, but then not out to the server (I obviously disabled the DNS lookup during this part). Annoyingly, I thought the issue might be the app, so deleted it and reinstalled it, now I can’t even log into the app. Anyone else had this?

Is there a way to get the shower on the LAN without the app? When I go to the shower, it actually says it’s connected to MITM (my Man in the Middle router), but I can’t see any connection or traffic on the router.

Without the app working I seem even more stuck?

Thanks folks.

[scudderfish]

The shower creates a wifi network that starts 'QSVC' that the app connects to. If you try to connect via something else, it wants a password. I assume that once connected there are either some API endpoints or even an http served page th set the actual credentials.

[scudderfish]

One of my showers got replaced, and the new one isn't playing ball. My MQTT server logs have this in them

1702470844: New connection from 192.168.103.226:59640 on port 8883.
1702470844: Client <unknown> closed its connection.
1702470859: New connection from 192.168.103.226:56345 on port 8883.
1702470859: Client <unknown> closed its connection.

so I've got a shower that doesn't accept my shonky certificate. <cracks knuckles>

[peterchs]

Sounds like the same behaviour I had before - is it working with the app and standard mqtt server? Mine didnt work with dns spoofed local mqtt until it had been properly onboarded/working via their app. For ages this wasnt working and failing at the last point after it connected to wifi. Something on the aqualisa end changed and it started working ok with the app and then I was able to swap in a dns spoofed local mqtt no issues.

There is a new AquaLisa app out btw.

[scudderfish]

Nope, I couldn't beat it into submission. I downloaded the official cert and then set all the fields I could to match but the shower wouldn't accept it.

[scudderfish]

@peterchs Only saw your message after I had posted mine :roll_eyes: I hadn't onboarded the new shower before I attempted this so I'll give that a go later.

[scudderfish]

That did the trick, provision it against Aqualisa without messing with DNS, then once it was online, set aqualisa-mqtt.like.st to point at my local MQTT server and all was good. Interestingly, although both showers claim to be the same unit and the same software version {"present":true,"part_num":"704230","sw_ver":"1","serial":"0652220631","flags":0} they login as different users to my broker. The older one logs in as its serial number, the newer one logs in as 'aqualisa'

TL;DR if you can't get it working, reprovision your shower using the new Aqualisa app before fiddling with DNS

[rodgers86]

My one that I can’t get working nor can I get in the new app now connects almost once a minute to

aqualisa-mqtt.vapor.red

I’ve contacted aqualisa as it just refuses to connect to the app. The process gets to the last bit where I enter my home WiFi details then fails

[cr3ative]

My one that I can’t get working nor can I get in the new app now connects almost once a minute to

aqualisa-mqtt.vapor.red

I’ve contacted aqualisa as it just refuses to connect to the app. The process gets to the last bit where I enter my home WiFi details then fails

Oh promising! New infrastructure!

https://docs.vapor.red/shutdown/

Oh

[scudderfish]

The shutdown text was merged into the website 5 years ago https://github.com/qutheory/red-docs/commit/8a1b54d0f8c61800c4dd3b30af21f8492513fdab

On Sat, 6 Jan 2024 at 09:53, Paul Curry @.***> wrote:

My one that I can’t get working nor can I get in the new app now connects almost once a minute to

aqualisa-mqtt.vapor.red

I’ve contacted aqualisa as it just refuses to connect to the app. The process gets to the last bit where I enter my home WiFi details then fails

Oh promising! New infrastructure!

https://docs.vapor.red/shutdown/

Oh

— Reply to this email directly, view it on GitHub https://github.com/cr3ative/homebridge-aqualisa/issues/10#issuecomment-1879619706, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEF5PLJHWHOWILX6OOJD7DYNENI7AVCNFSM6AAAAAAVQGAKTKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZZGYYTSNZQGY . You are receiving this because you modified the open/close state.Message ID: @.***>

[rodgers86]

That shower needs a new logic board…. Getting fixed next week!

[rodgers86]

Replacement shower installed. And Mqtt working.

I created an Mqtt climate entity using the data. And using custom simple thermostat card I’ve got this far so far.

Just need to add a timer bar card etc to it and start using it as a presence sensor to automate the extractor fan, lights and music!!

[paulandrewcrouch]

Glad you got it working. Would you mine sharing the YAML for this, I’d love to get mine into a climate card (unless I’m missing something really obvious)? Thanks.

[rodgers86]

Glad you got it working. Would you mine sharing the YAML for this, I’d love to get mine into a climate card (unless I’m missing something really obvious)? Thanks.

Work in Progress. Need to look at the fan_mode_state_template and also get the duration to play nice on the thermostat card, but here’s the configuration.yaml stuff.

mqtt:
  climate:
    - unique_id: ensuite_shower_climate
      name: "Ensuite Shower"
      current_temperature_topic: "0239220163/live/temperature"
      current_temperature_template: "{{ value_json.temperature / 100 }}"
      max_temp: 50
      min_temp: 15
      temperature_command_topic:  "0239220163/request/temperature"
      temperature_command_template: '{"temperature":{{ value * 100 | round(0)}} }'
      temperature_state_topic: "0239220163/request/temperature"
      temperature_state_template: "{{ value_json.temperature / 100 }}"
      swing_mode_command_topic:  "0239220163/request/outlet"
      swing_mode_command_template: '{"outlet":"{{value}}" }'
      swing_mode_state_topic:  "0239220163/live/outlet"
      swing_mode_state_template: "{{ value_json.outlet }}"
      swing_modes:
        - "A"
        - "B"
      fan_modes:
        - "low"
        - "medium"
        - "high"
      fan_mode_command_topic:  "0239220163/request/flow"
      fan_mode_command_template: >-
        {"flow":{% set values = {'low':'"Eco"', 'medium':'"Medium"', 'high':'"Max"'} %}
        {{values[value] if value in values.keys() }} }
      fan_mode_state_topic:  "0239220163/live/flow"
      fan_mode_state_template:  "{{ value_json.flow }}"

  switch:
    - unique_id: ensuite_shower
      name: "Ensuite Shower Switch"
      state_topic: "0239220163/live/onoffstate"
      command_topic: "0239220163/request/onoffstate"
      value_template: "{{ value_json.state }}"
      payload_on: '{"state":true}'
      payload_off: '{"state":false}'
      state_on: "True"
      state_off: "False"
      optimistic: false
      qos: 0
      retain: true

  sensor:
    - unique_id: ensuite_shower_duration
      name: "Ensuite Shower Duration"
      state_topic: "0239220163/live/time_run"
      value_template: "{{ value_json.time }}"
      device_class: "duration"
      icon: "mdi:timer"
      force_update: "true"

Here’s the link for the card Ive used as it’s fairly customisable.

https://github.com/nervetattoo/simple-thermostat/tree/master

And the code for the card itself as it stands. Again work in progress as i want to add the duration sensor in MM:SS and the State: Off is currently doing nothing. I think thats the “HVAC mode” which I’m not using in the climate entity.

type: custom:simple-thermostat
entity: climate.ensuite_shower
layout:
  mode:
    names: true
    headings: false
    icons: true
control:
  fan:
    high:
      name: Max
      icon: mdi:speedometer
    medium:
      name: Medium
      icon: mdi:speedometer-medium
    low:
      name: Eco
      icon: mdi:speedometer-slow
  swing:
    A:
      name: Drench
      icon: mdi:shower-head
    B:
      name: Shower
      icon: mdi:shower
header:
  toggle:
    entity: switch.ensuite_shower_switch
  icon: mdi:shower-head

Ill repost any updates.

[rodgers86]

Or using mini-climate-card

https://github.com/artem-sedykh/mini-climate-card

Instructions for this are pretty hard to get head around, but having used it for my Tado’s I’ve managed to quickly amend to create a very basic and minimalist shower version.

Card code below

type: custom:mini-climate
entity: climate.ensuite_shower
name: Ensuite Shower
icon: mdi:shower-head
toggle:
  hide: true
hide_current_temperature: true
target_temperature:
  step: 1
group: false
buttons:
  swing_mode:
    location: main
    type: dropdown
    icon: mdi:shower-head
    state:
      attribute: swing_mode
    change_action: >
      (selected, state, entity) => this.call_service('climate',
      'set_swing_mode', { entity_id: entity.entity_id, swing_mode: selected })
    source:
      A:
        icon: mdi:shower-head
        name: Drench
      B:
        icon: mdi:shower
        name: Shower
  f_mode:
    location: main
    type: dropdown
    icon: mdi:water
    state:
      attribute: fan_mode
    change_action: >
      (selected, state, entity) => this.call_service('climate', 'set_fan_mode',
      { entity_id: entity.entity_id, fan_mode: selected })
    source:
      low:
        icon: mdi:speedometer-slow
        name: Eco
      medium:
        icon: mdi:speedometer-medium
        name: Medium
      high:
        icon: mdi:speedometer
        name: Max
secondary_info:
  hide: true
hvac_mode:
  hide: true

[paulandrewcrouch]

Really grateful for this, many thanks. All set up now.

[rodgers86]

Really grateful for this, many thanks. All set up now.

I’ve made a few changes.

So the mqtt sensor for the duration… just so it’s formatted as mm:ss

#MQTT Sensors
  sensor:
    - unique_id: ensuite_shower_duration
      name: "Ensuite Shower Duration"
      state_topic: "0239220163/live/time_run"
      value_template: >-
       {{(value_json.time)|int|timestamp_custom('%M:%S') }}
      icon: "mdi:timer"
      force_update: "true"

Then for the card

type: custom:vertical-stack-in-card
cards:
  - type: custom:mushroom-entity-card
    entity: switch.ensuite_shower_switch
    icon: mdi:shower-head
    name: Ensuite Shower
    fill_container: false
    tap_action:
      action: toggle
    hold_action:
      action: none
    double_tap_action:
      action: none
    layout: horizontal
  - type: conditional
    conditions:
      - condition: state
        entity: switch.ensuite_shower_switch
        state: 'on'
    card:
      type: custom:simple-thermostat
      entity: climate.ensuite_shower
      tap_action: none
      version: 3
      decimals: 0
      step_size: 1
      layout:
        mode:
          names: true
          headings: false
          icons: true
      control:
        fan:
          high:
            name: Max
            icon: mdi:speedometer
          medium:
            name: Medium
            icon: mdi:speedometer-medium
          low:
            name: Eco
            icon: mdi:speedometer-slow
        swing:
          A:
            name: Drench
            icon: mdi:shower-head
          B:
            name: Shower
            icon: mdi:shower
      header: false
      sensors:
        - id: state
          entity: sensor.ensuite_shower_duration
          label: Duration
        - id: temperature
          label: '{{ui.currently}}'
          template: '{{current_temperature|formatNumber}}°C'

This requires

custom:vertical-stack-in-card https://github.com/ofekashery/vertical-stack-in-card

custom:mushroom-entity-card

https://github.com/piitaya/lovelace-mushroom

and the custom:simple-thermostat-card from earlier.

I’ve made the thermostat card conditional on the shower being on. As when you turn the shower on it automatically defaults to temperature etc, so as it stands you can’t preset. So no point showing the card while it’s switched off.

Should look like this.

Couple of card mod things to do to get rid of the border, and I do need to go back and look at the fan_mode_state_template so that it properly shows the current Flow level on the card.

[rodgers86]

      fan_mode_state_template: >-
        {% if (value_json.flow)=="Eco" %}
        low
        {% elif (value_json.flow)=="Medium" %}
        medium
        {% elif (value_json.flow)=="Max" %}
        high
        {% endif %}

This seems to work for fan_mode_state_topic

Means that if you change the setting on the shower it is reflected in the HA card.

I have tried sending new defaults to the default topic. But this writes them, but the shower ignores them. So I think the defaults will always be 39, medium flow and outlet A.

So only way of building presets would be to create a few scripts.

[jymbob]

@rodgers86 Thanks for all your work on the card. Just lifted verbatim, only needing to change the name and Aqualisa ID :+1:

[rodgers86]

Anybody have issues with the shower disconnecting from the broker and then connecting to the aqualisa broker?

I’m using adguard to do the dns rewrite. Is that where my problem lies?

Every couple of days I need to disconnect the router from WiFi and reconnect in order to force back to my broker.

I’ve created a sensor on homeassistant that tells me when it’s offline now so that I at least know when this needs done.

@scudderfish I see you used an extra router.

Is this set up as a network extender then? As I have an old TPLink extender kicking about that I could try.

My Eeros allow you to set the DNS servers and it does work. But after a while something slips and lets the showers call home. but I did wonder whether a separate network might work better.

[jymbob]

I'm running the dnsmasq addon on my HA server. My Google Wifi settings point DNS requests to that. Since I finally got it fully working it hasn't fallen off again, although it was flaky while I was fiddling with the setup

[jymbob]

Just been having a play, and I've got the timer working:

First publish to request/time_set with something like {"time": 300} then afterwards publish to request/onoffstate with {"state": true} and you'll get a shower running with the timer

I'm also sure I saw one situation where the temp I set AOT was honoured after a call to onoffstate to turn it on, but can't reproduce. Will investigate further

[peterchs]

Didnt know about the timer, nice. AOT? I've a button outside the shower that turns it on via XXXXX/request/onoffstate then 2s later change temp via XXXXX/request/temperature payload {temperature: 3700} and set max flow via XXXXX/request/flow payload {flow: "Max"} works well.

[jymbob]

Ahead Of Time

I have a similar script set up. Just thinking about whether to add a timer to it.