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.

[cr3ative]

FANTASTIC. Keep us updated!

[cr3ative]

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.

[scudderfish]

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.

[cr3ative]

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

[elgerg]

Same 🙂

[scudderfish]

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.

[cr3ative]

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.

[scudderfish]

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/

[scudderfish]

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

[cr3ative]

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?

[scudderfish]

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

[scudderfish]

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.

[cr3ative]

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?

[scudderfish]

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.

[scudderfish]

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.

[cr3ative]

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. :)

[cr3ative]

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.

[cr3ative]

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

[scudderfish]

It's a good job we don't have the client certificate as otherwise it could be possible to brute force all the showers into doing things.

On Wed, 8 Mar 2023 at 10:00, Paul Curry @.***> wrote:

[image: image] https://user-images.githubusercontent.com/1850718/223682623-7d220a09-7063-4da2-90e2-a355beca8c63.png

And this turns the shower off and on successfully.

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

[cr3ative]

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.

[cr3ative]

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.

[scudderfish]

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

[elgerg]

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

[cr3ative]

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

[Dantenz]

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

[scudderfish]

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 :)

[Dantenz]

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 🤷 )

[scudderfish]

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.

[paulandrewcrouch]

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.

[Dantenz]

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 https://github.com/cr3ative/homebridge-aqualisa/issues/10#issuecomment-1490593983, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJZ7IMQKKVPSREIFM3HNYJDW6WYJJANCNFSM6AAAAAAVQGAKTI . You are receiving this because you commented.Message ID: @.***>

[paulandrewcrouch]

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.

[paulandrewcrouch]

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.

[Whizzykid]

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!

[paulandrewcrouch]

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 :)

[peterchs]

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.

[peterchs]

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

[paulandrewcrouch]

I had to use EMQX and allow anonymous connections to get it to work. On 24 Jun 2023, at 02:06, Peter Stevenson @.***> wrote: 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 disconnected: Protocol error.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

[elgerg]

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 ?

[peterchs]

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.

[peterchs]

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.

[elgerg]

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

[peterchs]

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

[paulandrewcrouch]

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 }

[peterchs]

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!

[scudderfish]

Admittedly the certs I originally generated were as little as I could get away with. I certainly don't think I put the right server name in them. See if generating a new set with info as close as possible to the genuine ones helps.

Regards, David

On Wed, 26 Jul 2023 at 13:47, Peter Stevenson @.***> wrote:

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!

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

[peterchs]

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.

[paulandrewcrouch]

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.

[jymbob]

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

[peterchs]

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

[Mattrees007]

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.