MQTT about homebridge-aqualisa HOT 89 CLOSED

I had an epiphany in the shower (of all places) this morning. No need to grub around in the firmware, the shower will send to the MQTT broker the topics it wants to subscribe to. So I just whacked up the log level on the broker and got this out of it

1678262494: New client connected from 192.168.42.85:63871 as 0419220359 (p2, c1, k120, u'0419220359').
1678262494: No will message specified.
1678262494: Sending CONNACK to 0419220359 (0, 0)
1678262494: Received PUBLISH from 0419220359 (d0, q0, r1, m0, '0419220359/debug/heap', ... (16 bytes))
1678262494: Sending PUBLISH to local.gedgeMQTT (d0, q0, r1, m0, '0419220359/debug/heap', ... (16 bytes))
1678262494: Received SUBSCRIBE from 0419220359
1678262494:     0419220359/request/+ (QoS 0)
1678262494: 0419220359 0 0419220359/request/+
1678262494: Sending SUBACK to 0419220359
1678262494: Sending PUBLISH to 0419220359 (d0, q0, r1, m0, '0419220359/request/onoffstate', ... (48 bytes))
1678262494: Sending PUBLISH to 0419220359 (d0, q0, r1, m0, '0419220359/request/outlet', ... (24 bytes))
1678262494: Sending PUBLISH to 0419220359 (d0, q0, r1, m0, '0419220359/request/temperature', ... (30 bytes))
1678262494: Sending PUBLISH to 0419220359 (d0, q0, r1, m0, '0419220359/request/time_set', ... (43 bytes))
1678262494: Sending PUBLISH to 0419220359 (d0, q0, r1, m0, '0419220359/request/flow', ... (24 bytes))
1678262494: Sending PUBLISH to 0419220359 (d0, q0, r1, m0, '0419220359/request/profile', ... (23 bytes))
1678262494: Sending PUBLISH to 0419220359 (d0, q0, r1, m0, '0419220359/request/user', ... (23 bytes))
1678262494: Received SUBSCRIBE from 0419220359
1678262494:     0419220359/settings/# (QoS 0)
1678262494: 0419220359 0 0419220359/settings/#
1678262494: Sending SUBACK to 0419220359
1678262494: Sending PUBLISH to 0419220359 (d0, q0, r1, m0, '0419220359/settings/outlet/default', ... (30 bytes))
1678262494: Sending PUBLISH to 0419220359 (d0, q0, r1, m0, '0419220359/settings/temperature/default', ... (30 bytes))
1678262494: Sending PUBLISH to 0419220359 (d0, q0, r1, m0, '0419220359/settings/temperature/max', ... (30 bytes))
1678262494: Sending PUBLISH to 0419220359 (d0, q0, r1, m0, '0419220359/settings/timer/wateroff', ... (47 bytes))
1678262494: Received SUBSCRIBE from 0419220359
1678262494:     0419220359/experience/# (QoS 0)
1678262494: 0419220359 0 0419220359/experience/#
1678262494: Sending SUBACK to 0419220359
1678262494: Received SUBSCRIBE from 0419220359
1678262494:     0419220359/debug/# (QoS 0)
1678262494: 0419220359 0 0419220359/debug/#
1678262494: Sending SUBACK to 0419220359
1678262494: Sending PUBLISH to 0419220359 (d0, q0, r1, m0, '0419220359/debug/heap', ... (16 bytes))
1678262494: Received SUBSCRIBE from 0419220359
1678262494:     0419220359/request/+ (QoS 0)
1678262494: 0419220359 0 0419220359/request/+
1678262494: Sending SUBACK to 0419220359
1678262494: Sending PUBLISH to 0419220359 (d0, q0, r1, m0, '0419220359/request/onoffstate', ... (48 bytes))
1678262494: Sending PUBLISH to 0419220359 (d0, q0, r1, m0, '0419220359/request/outlet', ... (24 bytes))
1678262494: Sending PUBLISH to 0419220359 (d0, q0, r1, m0, '0419220359/request/temperature', ... (30 bytes))
1678262494: Sending PUBLISH to 0419220359 (d0, q0, r1, m0, '0419220359/request/time_set', ... (43 bytes))
1678262494: Sending PUBLISH to 0419220359 (d0, q0, r1, m0, '0419220359/request/flow', ... (24 bytes))
1678262494: Sending PUBLISH to 0419220359 (d0, q0, r1, m0, '0419220359/request/profile', ... (23 bytes))
1678262494: Sending PUBLISH to 0419220359 (d0, q0, r1, m0, '0419220359/request/user', ... (23 bytes))
1678262494: Received SUBSCRIBE from 0419220359
1678262494:     0419220359/settings/# (QoS 0)
1678262494: 0419220359 0 0419220359/settings/#
1678262494: Sending SUBACK to 0419220359
1678262494: Sending PUBLISH to 0419220359 (d0, q0, r1, m0, '0419220359/settings/outlet/default', ... (30 bytes))
1678262494: Sending PUBLISH to 0419220359 (d0, q0, r1, m0, '0419220359/settings/temperature/default', ... (30 bytes))
1678262494: Sending PUBLISH to 0419220359 (d0, q0, r1, m0, '0419220359/settings/temperature/max', ... (30 bytes))
1678262494: Sending PUBLISH to 0419220359 (d0, q0, r1, m0, '0419220359/settings/timer/wateroff', ... (47 bytes))
1678262494: Received SUBSCRIBE from 0419220359
1678262494:     0419220359/experience/# (QoS 0)
1678262494: 0419220359 0 0419220359/experience/#
1678262494: Sending SUBACK to 0419220359
1678262494: Received SUBSCRIBE from 0419220359
1678262494:     0419220359/debug/# (QoS 0)
1678262494: 0419220359 0 0419220359/debug/#
1678262494: Sending SUBACK to 0419220359

Therefore the things the shower is listening to are

<id>/request/+
<id>/settings/#
<id>/experience/# 
<id>/debug/#

Now I need to read the docs to find out what those wild-card characters mean.

from homebridge-aqualisa.

Small update, having just seen the shower run, the request section is what the user in the shower has asked for, live is what the shower is actually doing. Poking true into request/onoffstate doesn't turn the shower on if it is off, so request is just a reporting channel. The controller is listening to something else which I'll need to proxy.
Just had a thought, I should really use wireshark to capture all traffic to/from the shower to check my assumption that it's controlled over MQTT.

from homebridge-aqualisa.

The shower doesn't care what MQTT broker it connects to, however we don't know what Aqualisa sends back that the shower is listening for. If we could get the firmware image we could possibly pull out the client cert or look for strings that look like topic names. If we know the topic names, we can probably make educated guesses about the json objects to post to them to get the shower to do our bidding.

from homebridge-aqualisa.

It'll be the pump box. I found an installation manual (I was hoping for a full tech service manual) showing the wiring. There just isn't enough stuff coming from the controls for it to make sense that the 'brains' are there.

from homebridge-aqualisa.

I'll see if I can find the time to complete this plugin at some point I suppose. :)

from homebridge-aqualisa.

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.

from homebridge-aqualisa.

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.

from homebridge-aqualisa.

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.

from homebridge-aqualisa.

FANTASTIC. Keep us updated!

from homebridge-aqualisa.

FWIW, my suspicion is that the product uses the AWS IoT MQTT cloud offering, which is pretty secure by default - pinned certificates and such - but it's worth a try. It doesn't appear to talk to the "nodes" servers. You may be able find more about that if you agree with my suspicions - this isn't a route I've extensively looked in to.

The "silent port" may accept MQTT messages. I haven't been able to find out because I don't know what the valid messages look like. If it does, that would allow us to write for local control without DNS hacks either.

from homebridge-aqualisa.

The shower doesn't seem to care who it talks to, it does no sort of validation. I hope I can just transparently proxy the connection where the shower presents its client cert and then just dump to packets to stdout.
One thing I didn't notice until after I'd torn it all down is that there are both 'live' and 'request' topics. It may be as simple as poking things into 'request'. An experiment for tomorrow night.

from homebridge-aqualisa.

That is absolutely remarkable. Can't wait for you to proxy and discover the commands.

from homebridge-aqualisa.

Same 🙂

from homebridge-aqualisa.

I've looked at some wireshark traffic between the shower and my WiFi points, and agree with your guess that it's entirely MQTT once operating, with just a little bootstrap DNS and NTP.

I agree that the app triggers an MQTT command from a central server, nothing direct.

I don't think it currently has an exposed local API though one appears to have been planned from translation files.

from homebridge-aqualisa.

If there is a client cert, I'm think I'm stuck. I wasn't thinking straight, I had it in my head that the client cert worked at the app level (equivalent to user/pw), but it works at the socket connection level so I won't be able to get my proxy to connect to aqualisa pretending to be my shower. For now, this may be a read-only way of extracting information.

I assume the device is an ESP8266 (cheap, they didn't bother changing the network name from 'espressif', the default 192.168.4.1 IP address), so it may be a case of opening up the shower, looking for some uart pins and doing something like this https://steve.fi/hardware/backup-and-restore/

from homebridge-aqualisa.

TBH, read only would make my wife happy as she's convinced I'm going to set it to cold on her for giggles.

from homebridge-aqualisa.

I'm going to have to learn more about MQTT. Would you mind writing up the steps to get where you are?

Are you saying it might emit blindly, but require some kind of authenticated write maybe?

from homebridge-aqualisa.

OK, I've added a README here https://github.com/scudderfish/MQTT-MITM

from homebridge-aqualisa.

Gotcha. So we know how to send it stuff but not what to send it. I'd love to play with that and will shortly!

Our of interest do you suspect the Espressif device is in the control pad or the pump box?

from homebridge-aqualisa.

Amazing. I'm away from my systems at the moment or I'd be on this too.

It's VERY promising that it accepts settings, as turning off the bath fill timer (or adjusting it) would make my year. I'm sure we can figure it out!

At a guess? Same names as the readouts it emits. :)

from homebridge-aqualisa.

Hahaha. Yes. YES!
Your repo was incredibly helpful in getting this going. Mosquitto in an unRAID container, rule in the firewall to let the shower talk to unraid, we're away.

from homebridge-aqualisa.

This turns the shower off and on successfully. I'm looking in to my much-hated "wateroff" timer to see if the setting sticks.

from homebridge-aqualisa.

from homebridge-aqualisa.

Oh, I have full faith in the Aqualisa Shower Corporation that each client certificate would only permit access to a single shower, as configured.

Complete faith.

from homebridge-aqualisa.

Confirming temperature set while running works great too; it seems like things really are by natural expectation:

This updates the screen on the shower controller, same as it does from the app or turning the knob. Lovely stuff.

from homebridge-aqualisa.

It works for me too! Now to set it all up in Home Assistant......

from homebridge-aqualisa.

OMG! This is amazing.

After enabling secure/tls on my broker per your docs (need really to include the listener 1883 0.0.0.0 bit as the config drops non-secure connections) all worked brilliantly.

You're not kidding about the spam. Mine cant make it's mind up if 44 or 45 degrees is the max or not. That and the counter that checks in every second..

Other than that, I have my Node-Red/MQTT integration working brilliantly!

I can turn the shower on using Alexa and it sets the correct temp and sets it to "Eco" mode at the same time.

I might adjust it to do max to get near the target temp, maybe 10 secs then Eco after.

Thanks for the effort!!!

from homebridge-aqualisa.

I saw my inbox light up earlier this week with some chatter and I was not disappointed. I am now able to control my bath and shower units through MQTT. Awesome work!

I ran into one problem, which was that I already have a mosquitto broker up and running with a listener that demands authentication. By default, mosquitto applies the same auth requirements to all listeners, which meant the shower was being denied access, even though anonymous access was enabled:
Client <unknown> disconnected, not authorised.

To get around this I set per_listener_settings true in the main mosquitto.conf:

I'm on openhab, so will be setting up a custom piece of equipment which basically sits on the back of mqtt service addon.

On the debug topic - I kinda feel that should be disabled by default?!

from homebridge-aqualisa.

I did worry about that myself but then realised that client auth over 1883 is just one sniffed packet away from compromise so I turned off auth. If someone is in my network, MQTT user/password is not going to help, and is probably the least of my worries.

I'd hate to think what fraction of the aqualisa AWS network ingress bill is caused by all those showers firing all those debug messages :)

from homebridge-aqualisa.

Seems like it's just the heap and two timestamps causing the majority of traffic. I have so many questions - it seems like someone did a decent job then just gave up right at the end. Feels like most of this was outsourced at some point.

I'm of the same opinion with network security, but this is a requirement forced by openhab (which could be run on less than secure networks 🤷 )

from homebridge-aqualisa.

One idea I did toy with was running a separate broker that only does 8883 and then using the bridge functionality of mosquitto to pull/push that data into the main system. I thought it'd be doable on an ESP32 but none of the MQTT servers I could find supported TLS out of the box and I didn't have the umph to fight it.

from homebridge-aqualisa.

I have now spent 2 days and 3 4am finishes trying to get this to work. I've got the shower into an old wireless router that allows a DNS server and that is pointing successfully to my Home Assistant on Raspberry Pi. I can see the request come into the Mosquitto Broker, but it says SSL connection failed.

I wonder if any SSL experts can help. Because I use Mosquitto Broker Add On, the file structure is different, and because I use DuckDns and LetsEncrypt I don't have a cafile. I've been searching high and low, nothing on letsencrypt.org works, including the root and intermediary. I have a fullchain.pem file and a privkey.pem but no cafile. The files on this thread don't work. Any thoughts? Unsure if relevant but I also have NGINX however the traffic to Mosquitto Broker is local.

I feel I'm on the brink of success, yet miles away! My error is below.

Thanks in advance.

2023-03-30 17:22:52: New connection from 192.168.1.105:50592 on port 8883.
2023-03-30 17:22:53: OpenSSL Error[0]: error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed
2023-03-30 17:22:53: Client disconnected: Protocol error.

from homebridge-aqualisa.

from homebridge-aqualisa.

I'm not familiar with your entire setup, but it seems the issue is with your auth method. The ca file provided in this thread works for me, so I'd be tempted to give that another go - initial thoughts are your setup shouldn't matter. In the docs for the mosquito addon it takes a ca file: https://github.com/home-assistant/addons/blob/master/mosquitto/DOCS.md Try uploading the ca files provided to a location the addon can read from and then update the config to use the ca. Report back with error if it doesn't work
…
On Thu, 30 Mar 2023, 17:30 paulandrewcrouch, @.> wrote: I have no spent 2 days and 3 4am finishes trying to get this to work. I've got the shower into an old wireless router that allows a DNS server and that is pointing successfully to my Home Assistant on Raspberry Pi. I can see the request come into the Mosquitto Broker, but it says SSL connection failed. I wonder if any SSL experts can help. Because I use Mosquitto Broker Add On, the file structure is different, and because I use DuckDns and LetsEncrypt I don't have a cafile. I've been searching high and low, nothing on letsencrypt.org works, including the root and intermediary. I have a fullchain.pem file and a privkey.pem but no cafile. The files on this thread don't work. Any thoughts? Unsure if relevant but I also have NGINX however the traffic to Mosquitto Broker is local. I feel I'm on the brink of success, yet miles away! My error is below. Thanks in advance. 2023-03-30 17:22:52: New connection from 192.168.1.105:50592 on port 8883. 2023-03-30 17:22:53: OpenSSL Error[0]: error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed 2023-03-30 17:22:53: Client disconnected: Protocol error. — Reply to this email directly, view it on GitHub <#10 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJZ7IMQKKVPSREIFM3HNYJDW6WYJJANCNFSM6AAAAAAVQGAKTI . You are receiving this because you commented.Message ID: @.>

Got it working brilliantly, gave up with Mosquitto Broker and downloaded EMQX, gave me quite a bit more control. Absolutely loving it. All automated with scripts, input helpers, the lot. Awesome job guys.

from homebridge-aqualisa.

Just to add, now have this into Home Assistant, Ethernet Zigbee bridge for a set of buttons on the wall for the family and it works flawlessly. Thank you so much for your hard work. I suspect with a bit of playing I could get Mosquitto Broker to work, but EMQX is giving me much more flexibility and insight anyway so a double win.

Best wishes all.

from homebridge-aqualisa.

Great work from all involved here! Sorry to be a total novice, but is there a 'for dummies' guide to getting this set up and working in Home Assistant?
Thanks!

from homebridge-aqualisa.

Great work from all involved here! Sorry to be a total novice, but is there a 'for dummies' guide to getting this set up and working in Home Assistant? Thanks!

@scudderfish put up a Readme (above in the link) on how to do it. I had to do a couple of extra things. BT routers in the UK don't DNS routing, so the shower is connected to a £30 Mango travel router on a hidden network, and that allows me to specific a DNS server. I have Dnsmasq on the home assistant that then points aqualisa-like.st to the MQTT broker. THat's where I got stuck and had to download EMQX as a new broker, I couldn't get authentication to work on Mosquitto Broker.

What then took the time was writing scripts and drop downs for the kids and getting my Moes 12 Way switch to work. Happy to share the Yaml if helpful for that. Basically just publishes different commands.

It is awesome now :)

from homebridge-aqualisa.

Not having much luck, using the certs here just keep getting protcol error in mosquitto logs when the shower connects. I'm able to connect ok to the same broker/port using tls via node red, its just the shower thats not connecting. I've just bought the shower unless the firmware has changed?

Mosquitto log:

1687564961: New connection from 192.168.1.7:60074 on port 8883.
1687564961: Client <unknown> disconnected: Protocol error.

from homebridge-aqualisa.

@paulandrewcrouch Not having any luck with mosquitto either. Was there any special config for emqx needed to get it working? Did you change the ootb cert configuration? Did try it but didnt see any client connections from the shower, but my node red could connect fine using the hostname/port/tls. I'm hoping I dont have newer firmware with client certs or pinning or something.

from homebridge-aqualisa.

from homebridge-aqualisa.

Hi @peterchs / @paulandrewcrouch

What does your mosquitto config look like?

I created a conf file in /etc/mosquitto/conf.d

Called shower.conf

That looks like:

listener 1883 0.0.0.0

listener 8883  0.0.0.0
allow_anonymous true
tls_version tlsv1.2
cafile /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/server.crt
keyfile /etc/mosquitto/certs/server.key
connection_messages true

When you set yours up did you create the certs as well/pull them from https://github.com/scudderfish/MQTT-MITM/tree/master/certs ?

from homebridge-aqualisa.

hi @elgerg yes using the certs from here put in /etc/mosquitto/conf.d

my shower.conf is

listener 8883  0.0.0.0
allow_anonymous true
tls_version tlsv1.2
cafile /etc/mosquitto/conf.d/ca.crt
certfile /etc/mosquitto/conf.d/server.crt
keyfile /etc/mosquitto/conf.d/server.key
connection_messages true

Will try different paths like yours and double check permissions. openssl s_client test seems to work ok though can see cert presented on that test.

Thanks @paulandrewcrouch will try emqx again later and make sure to enable the anon auth.

from homebridge-aqualisa.

After a lot of attempts I've given up - think I have a newer firmware Quartz Touch which has cert pinning/checks. I am still just getting protocol error when the shower attempts to connect to my broker and EMQX doesnt work either. I've got a wireshark capture and I can it is failing in the TLS handshake, even before the client hello - so I think the the shower doesnt like my cert.

I'd be interested if anyone else has a quartz touch, check the rev-build to confirm my suspicion that i've a newer firmware than the rest of you - on the device info it shows - Part No: 704272 and Rev-build: 05-13422 - what rev-build does it show for those who have it working?

Its rather rubbish - cant get even the standard smart functions working as the standard Aqualisa app wont even add my shower into it - it fails on the last step, but its definitely connecting to my wifi ok.

from homebridge-aqualisa.

Where are you seeing the rev-build? I'll check mine if it helps..

from homebridge-aqualisa.

If you go into the settings on the control, 'about my q'.

from homebridge-aqualisa.

After a lot of attempts I've given up - think I have a newer firmware Quartz Touch which has cert pinning/checks. I am still just getting protocol error when the shower attempts to connect to my broker and EMQX doesnt work either. I've got a wireshark capture and I can it is failing in the TLS handshake, even before the client hello - so I think the the shower doesnt like my cert.

I'd be interested if anyone else has a quartz touch, check the rev-build to confirm my suspicion that i've a newer firmware than the rest of you - on the device info it shows - Part No: 704272 and Rev-build: 05-13422 - what rev-build does it show for those who have it working?

Its rather rubbish - cant get even the standard smart functions working as the standard Aqualisa app wont even add my shower into it - it fails on the last step, but its definitely connecting to my wifi ok.

I'm happy to send over the certs I'm using if helpful. I had to allow EMQX to accept anonymous users.

Message 523 received on 0412220564/info/qsvc at 16:31:
{
"present": true,
"part_num": "704230",
"sw_ver": "1",
"serial": "0412220564",
"flags": 0
}

Message 524 received on 0412220564/info/controller at 16:32:
{
"present": true,
"part_num": "704478",
"sw_ver": "2",
"serial": "0120220040",
"flags": 0
}

from homebridge-aqualisa.

Did too much digging on this spent too much time with no luck. Tcpdump from my AP in wireshark shows the connection starting then even before the client hello in the tls handshake the shower drops the connection. Same if I try an openssl test server to try and debug it. Tried different servers on diff boxes, recreated different certs many times. I do think its a newer shower firmware with cert pinning/validity checks.

Crappy thing is AquaLisa current apps (tried both ios+android) do not work with my shower cant onboard it fails at last point, and so cant even try to use the standard AquaLisa smart functions. "next month" their support says it'll be fixed, seems they have been saying similar for quite some time based on the app reviews. They continue to heavily market smart features of this device too :( Ironic thing is I think the problem with the shower and the standard features not working is down to the shower failing to connect properly to the standard AquaLisa MQTT server - see it repeatively attemping connections in tcpdumps. Perhaps there is a plan to switch to a new mqtt server in future which will work with my shower. But at present its broken. If only I could downgrade the shower firmware somehow.

Having said all this, I'm still up for trying EMQX again anyway if you can try attaching certs on here? Thanks!

from homebridge-aqualisa.

from homebridge-aqualisa.

Cheers for the suggestion - have tried that copying everything from the cert presented by the AquaLisa server to a self signed one (hostname/CN) included used by my local mosquitto, but no dice same behaviour.

from homebridge-aqualisa.

Cheers for the suggestion - have tried that copying everything from the cert presented by the AquaLisa server to a self signed one (hostname/CN) included used by my local mosquitto, but no dice same behaviour.

That does sound exactly what happened to me, which was resolved when I moved to EMQX and allowed anonymous connection.

from homebridge-aqualisa.

@peterchs I'm still fighting (my EMQX install appears to be ... missing some files??) but worth mentioning: The HA Mosquitto add-on no longer supports anonymous connections. At all. I found it briefly mentioned in a closed github issue of all places. One of those infuriating "yeah, we decided it was insecure so we disabled it forever, NBD, not worth documenting" changes that happens with open-source projects.

from homebridge-aqualisa.

I'm not using HA version of mosquitto just regular mosquitto/EMQX server on Ubuntu/Debian. Have configured it with anonymous only. Tried different servers - same thing.

My shower cant even connect to the proper aqualisa MQTT server based on wireshark dumps - the shower drops the connection before even the TLS hello. A dns spoofed local mosquitto/emqx server and the shower does the same. Thus my expectation that I have broken shower firmware. Broken shower firmware would also explain why there are so many normal users on the app review experiencing the same problem as me (cant onboard the shower to the app fails at last point).

from homebridge-aqualisa.

I'm not using HA version of mosquitto just regular mosquitto/EMQX server on Ubuntu/Debian. Have configured it with anonymous only. Tried different servers - same thing.

My shower cant even connect to the proper aqualisa MQTT server based on wireshark dumps - the shower drops the connection before even the TLS hello. A dns spoofed local mosquitto/emqx server and the shower does the same. Thus my expectation that I have broken shower firmware. Broken shower firmware would also explain why there are so many normal users on the app review experiencing the same problem as me (cant onboard the shower to the app fails at last point).

Hi. Which shower are you trying to connect with?

Kudos to the guys above, but im in the same boat. I cant get past "Client disconnected: Protocol error."
ive tried @scudderfish certs and tried generating my own.

from homebridge-aqualisa.

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

from homebridge-aqualisa.

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

from homebridge-aqualisa.

from homebridge-aqualisa.

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.

from homebridge-aqualisa.

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

from homebridge-aqualisa.

from homebridge-aqualisa.

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.

from homebridge-aqualisa.

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.

from homebridge-aqualisa.

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.

from homebridge-aqualisa.

from homebridge-aqualisa.

@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.

from homebridge-aqualisa.

from homebridge-aqualisa.

from homebridge-aqualisa.

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.

from homebridge-aqualisa.

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.

from homebridge-aqualisa.

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>

from homebridge-aqualisa.

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.

from homebridge-aqualisa.

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.

from homebridge-aqualisa.

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

from homebridge-aqualisa.

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

from homebridge-aqualisa.

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

from homebridge-aqualisa.

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

from homebridge-aqualisa.

from homebridge-aqualisa.

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

from homebridge-aqualisa.

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!!

from homebridge-aqualisa.

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.

from homebridge-aqualisa.

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.

from homebridge-aqualisa.

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

from homebridge-aqualisa.

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

from homebridge-aqualisa.

      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.

from homebridge-aqualisa.

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

from homebridge-aqualisa.

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.

from homebridge-aqualisa.

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

from homebridge-aqualisa.

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

from homebridge-aqualisa.

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.

from homebridge-aqualisa.

Ahead Of Time

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

from homebridge-aqualisa.