Status

[starsoccer]

Just checking to see if this still works as expected? I recently tried to set one up and am having weird issues where nothing is being reported via mqtt

[starsoccer]

Is there any way to debug issues setting this up further. Ive hit a wall at this point and cant seem to figure out what the issue is.

I setup the custom dns server, and have confirmed the dns server is working as expected. If I try to make a request it goes to my docker container. I also confirmed on the dns server itself(pi hole), that its getting 2 dns requests from the monitor.

1. energysmartwaterheater.com
2. devices.irissmarthome.com

Not sure what the second one is for exactly, but the first one is 100% redirected. For context I have confirmed the docker container is accessible starting with the webserver itself where I can hit it by going to https://energysmartwaterheater.com. I can go in browser, it gives a cert error, which I can ignore and confirm it says not found. I also for sanity sake tried copying what an example payload looks like and was able to get it to successfully see the payload and publish it on mqtt, but my device itself for some reason is failing to talk to the docker container

For sanity sake I also tried doing something even more basic and creating a super simple webserver that just logs the path hit and put it behind the enerysmart proxy. Again I tested with a post, confirming I was able to hit it successfully but the energysmart module doesnt seem to be making any requests to it. So I am a bit out of ideas at this point.

Example app listening on port 8001
/~branecky/postAll.php

Short of cutting it to an MITM Proxy to just log all requests it makes I am not sure what else to try. If anyone has any ideas/suggestions of things to try I am open to almost anything at this point to try to get something more then dns requests from it.

[rwagoner]

Yes I'm still using this to integrate my water heater with Home Assistant. However I'm not developing it further since the product has been discontinued.

Are you using docker-compose to start both the Nginx proxy and EnergySmartBridge? The bridge container will show a log entry when the module makes a request, similar to the below (sanitized).

EnergySmartBridge.Modules.MQTTModule: 2023-09-05 10:34:33,509 DEBUG: URL: /~branecky/postAll.php
DeviceText=&Password=&ModuleApi=1.5&ModFwVer=3.1&MasterFwVer=06.03&MasterModelId=B1.00&DisplayFwVer=03.04&WifiFwVer=C2.4.0.3.AO7&UpdateRate=60&Mode=EnergySmart&SetPoint=120&Units=F&LeakDetect=NotDetected&MaxSetPoint=120&Grid=Disabled&AvailableModes=Standard,Vacation,EnergySmart&SystemInHeating=False&HotWaterVol=High&Leak=None&DryFire=None&ElementFail=None&TankSensorFail=None&EcoError=False&MasterDispFail=None&UpperTemp=119&LowerTemp=109&FaultCodes=0&UnConnectNumber=7&AddrData=&SignalStrength=-32

[starsoccer]

@rwagoner Yes I am. So I am running both containers using unraid. I actually forked your code and added some github actions to auto build the 2 separate containers and then have them both running in unraid, where the proxy is on its own IP with 443 exposed and then the other container with just 8001 exposed also on its own IP.

Edit: For sanity sake I did try running docker-compose natively on a mac to rule out unraid as an issue. This sadly didnt change anything. No requests make it to the mac, but I could still hit it from any other machine

What I really cant just figure out/understand is why it works for me on every other machine fine. From reading the manual that came with the module(one too many times) it says solid green indicates no internet connectivity. So I am curious if this is an indicator as to part of the problem or if its just because the other domain, devices.irissmarthome.com is down.

Any idea if your indicator light blinks or is just solid like mine?

[starsoccer]

Just for sanity sake I just tried to ping from the nginx proxy to the device and can confirm pings work(atleast one way) to it. So I know the proxy can hit the device in theory make requests to it. I just dont know what the issue with the device talking to the proxy is.

My gut says its networking related, but Ive ruled that out as best I can. I set it to a static IP, confirmed that IP can hit the device. Changed my machines IP to be the previous static IP and verified it still works

[starsoccer]

For even further sanity, I had a mini router that can broadcast its own wifi network, etc.. So I decided to set that up, have it set the dns server as the same pi hole. Then on another machine I connected to this new wifi, and verified I was able to hit the docker container using the energy smart url. This worked all without issue.

So I tried to hook the module up to the same wifi network but sadly still no luck. So I am running out of ideas on what to try at this point. Any suggestions/ideas welcome.

Screenshot below of my pi hole setup. Unless its my pihole setup I am not sure what else the issue could be at this point. I tried to rule this out as best I could by actually taking this other wifi network and only having it point to the pihole and then run nslookup vs when not going through the pihole. Pic attached of that as well.

[starsoccer]

@rwagoner Any guidance on how you logged traffic to/from the device? Was looking at setting up a proxy and seeing what it sends out to try to debug further

[starsoccer]

Any further information you can provide? I have started down the long road of attempting to mitm the device but hitting a wall with the tls. It seems to be saying it supports AES256_CBC_SHA, AES128_CBC_SHA, and then RC_128_M5 but I cant get it to talk to mitmproxy or s_server with any of those ciphers set.

Are you sure client authentication isnt needed even if its just discarded?

[mefbgil]

I changed the first line in the Dockerfile in the energysmart-proxy folder from “nginx:latest” to “nginx:1.25.0” and that fixed it for me. Been stable on refreshed builds as well.

[starsoccer]

I changed the first line in the Dockerfile in the energysmart-proxy folder from “nginx:latest” to “nginx:1.25.0” and that fixed it for me. Been stable on refreshed builds as well.

I was hopeful that would just magically fix it for me, but no luck so far. Going to play with it a bit more just to be make sure its 100% hitting the container still. Any other advice, or guidance as to how you figured that out so I can try to troubleshoot further?

[starsoccer]

I take that back. I missed a dns setting it seems and now after fixing that it works. Wow @rwagoner any objection if I make some PRs for this repo to do do the above change, add github actions, and possibly automated homeassistant integration?

@mefbgil I owe you big time. Ive been banging my head against this for days/weeks

[starsoccer]

Follow up question, does your device get auto added to homeassistant via the mqtt integration or did you manually configure it?

Right now I see the mqtt topics but don't see any entity or device in the mqtt integration

[mefbgil]

Yes, they had a couple of years back when I originally turned this on. MQTT integration changed a few months back and then I had to manually config.

[starsoccer]

Yes, they had a couple of years back when I originally turned this on. MQTT integration changed a few months back and then I had to manually config.

Okay interesting. I am going to try to work on fixing that. Also probably going to also try to move it to the current device type which would be water heater instead of a hvac unit which is how its currently setup, https://www.home-assistant.io/integrations/water_heater.mqtt/

@rwagoner happy to contribute to this project if your open to it. Otherwise Ill probably keep building on this in my own fork

[rwagoner]

@starsoccer Check the dev branch, which has some changes for MQTT discovery. I need to release those to master. That branch defiantly works as it's the same code I use for the OmniLinkBridge project.

I rebuilt my nginx docker and am seeing the same issue where the device no longer connects. The 1.25 docker hash is 9504f3f64a3f, which matches latest. I'll see if I can determine which nginx version actually works. The device is outdated and the SSL protocol is way behind. If I had the time I'd prefer to reverse engineer the device to water heater protocol and just replace it with an ESP32 or similar.

[starsoccer]

@rwagoner Okay will work on pulling those changes into my fork. My fork is auto building the images with github actions as I am using unraid. It would be great if this was a HA addon. I did see another repo about that, but couldnt get it to work either.

Regarding reverse engineering, when I was researching there was someone who did a tear down and semi reverse engineer with wemo d1 here, https://www.instructables.com/AO-Smith-Water-Heater-Monitor-Lowes-IRIS/ Otherwise it seems like the CTA-2045 standard is being rebranded to EcoPort or OpenADR and there are some devices and such here, https://www.openadr.org/ecoport-info that may make your life easier. The one device I saw was expensive(200$) though compared to a under 10$ for these.

[rwagoner]

For me rolling back to nginx:1.24 resolves it. I've tested 1.25 twice and both times I see no requests from the device. I'll commit that change to the dev repo and bring them over to master.

@starsoccer I'm opening to switching to the MQTT water heater item vs climate. Do you know if it allows you to still see the history graph with temps and heating like climate does?

[starsoccer]

So Im a bit concerned about changing it to 1.24 honestly. 1.25 is what works for me. Im surprised 1.25 doesnt work for you. Or did you perhaps mean 1.26?

@rwagoner Regarding the mqtt swtich, I dont know offhand as I have no mqtt water heater devices but I just think thats the best place for it.

I also did just try the dev changes, and while they work and the device is auto discovered it doesnt appear with any entities which isnt great so I think it still needs more work regardless. Im happy to pitch in and help make improvements

[rwagoner]

Just realized you were testing 1.25.0, not 1.25. I tested that version and can confirm nginx:1.25.0 does work. I also tested 1.25.1, which does not work. Nginx.org shows 1.24 as stable and 1.25 as mainline, adding HTTP/3 support. I'd prefer to pin 1.24 vs 1.25.0 so security updates will still be received.

[starsoccer]

Ah okay makes sense. I have no objection with that then.

So is there anything I can do to assist with getting all these changes made? List below of changes Id personally like to be made not saying we are in agreement on all of these:

1. Change nginx to use above decided docker tag
2. Fix HA autodiscovery not working for mqtt hvac
3. Change HA autodiscovery to use water heater instead of hvac
4. Add automated building of docker images in pipeline(part of this being making some more things configurable)
5. Add ability to run as a HA addon
6. Add indicator if device is in remote administration mode or not(not sure if this is possible with the current device though)

[rwagoner]

I'm happy to accept a PR with your changes.

1. I pushed the docker tag change to the dev branch.
2. I am able to replicate this issue where the entities are not being associated with the device. I compared the discovery json and the issue is not readily apparent. This will need more investigating.
3. I agree the water heater device type should be migrated to over the climate type assuming functionality isn't lost.
4. I'm open to this and had auto builds for another project with docker hub before they required paid plans.
5. I crated an add-on in the past, but only got it working using the Home Assistant base docker image. If you have knowledge in this area that would be great.
6. This would be great. I have to check my water heater and hit the grid button after a power outage. I mainly use the Home Assistant integration for monitoring at this point.

[starsoccer]

@rwagoner Okay so to address 4 I just put up a PR, https://github.com/excaliburpartners/EnergySmartBridge/pull/7

Are you working on 2 & 3? If So I can start to work on 5 or 6 so we dont overlap

[starsoccer]

So I got 6 working roughly on my master branch. But not sure how to validate if control is working properly. I changed the temp by putting it up 1 degree and I saw the logs say it was queued up. Then on the next energybridge connection it says sent queued on the first connection, but then it seems like it errors or somehow gets in a bad state as it then tried to connect a total of ~10 times in a 80 second span sending all the same information over and over again

When I went and physically checked the unit it still said the old setpoint(125F) not the new one, 126.

Another oddity I noticed is you can it seems queue up multiple commands but it seems like it would be best to just use whatever the last queued command was.

[starsoccer]

bump on the above for controlling the temp. I havent had much luck so far

[cmonteiro128]

+1 for changing the device type in Home Assistant to water heater!

[Boohooligan]

I'm not sure what I'm doing wrong here. Have a new smart module connected to my AO Smith hybrid water heater that has the same port on it. I've used multiple versions of this from git, currently running the dev branch from excalibur. Home Assistant MQTT Broker is showing the connection and MQTT Explorer shows the energysmart topic but the only thing that has been sent is status=online.

I used pi-hole to redirect the smart module to the docker server and I can see the queries being answered with the local address. The router captures and redirects all port 53 requests to the pihole so I don't think it's getting around it somehow.

Not sure what the issue could be. I'm also not SUPER familiar with docker so beyond using docker logs I'm not sure how to see what the issue might be. Any guidance?

[starsoccer]

Yeah sadly this project doesnt seem to be too supported. When I get some time I am going to clean up my fork and try to make things easier to setup.

As for your issue, I am not sure off hand, but I would for sure check the nginx version thats what seemed to cause issues in the past if you review this and the other thread. Sorry I cant be more help at the moment

[Boohooligan]

Thanks for responding. Since I grabbed the dev branch it looks like the version was set as previously mentioned in this thread. Do you know how I can see connection logs for the proxy to see if the smart module is even sending anything to it?

[Boohooligan]

Looks like for whatever reason the bridge container won't expose port 8001. At least as far as I can tell it isn't exposing it. When I run the docker port [container] 8001/tcp I get a message that there's no public port on that container. Though I can ping the bridge container from the proxy. This is incredibly difficult to troubleshoot.

Wireshark shows the module shaking hands with the proxy but after the certificate is offered up the module ends the transmission, sending a fin ack.

[starsoccer]

To be totally honest it sounds like your using the bad nginx. If you want to make an issue on my fork Ill try to assist you over there to avoid this thread being derailed further

[Boohooligan]

Issues seem disabled for your fork at this time.

[starsoccer]

Issues seem disabled for your fork at this time.

Fixed now

[starsoccer]

For anyone else running into issues using this just noting I have forked this project and have converted it into a HA addon. On top of that Ive also fixed the auto discovery and corrected it to be for a water heater not climate. Ive also exposed a few of the other sensors directly on the device

[cmonteiro128]

Appreciate it @starsoccer! Will be trying your fork out soon

[mefbgil]

Exciting! I had exposed the leak detection sensor myself. I'm going to try your version and see how it goes this afternoon.

[Boohooligan]

I've been testing for starsoccer and it is really impressive what this turned into, especially not needing another piece of hardware to run it on.

[mefbgil]

No luck - this is what I get in the logs. I get the "ERROR: SendResponse" every time the module reports status, so I know the nginx layer is working and talking to the bridge. Any ideas?

Listing Versions! nginx version: nginx/1.24.0 grep: /data/options.json: No such file or directory EnergySmartBridge.Modules.WebServerModule: 2024-01-27 13:12:13,446 INFO : Listening on http://*:8001/ EnergySmartBridge.Modules.WebServerModule: 2024-01-27 13:12:18,940 ERROR: SendResponse System.NullReferenceException: Object reference not set to an instance of an object at EnergySmartBridge.Modules.MQTTModule.PublishWaterHeaterState (EnergySmartBridge.WebService.WaterHeaterInput waterHeater) [0x002ad] in :0 at EnergySmartBridge.Modules.MQTTModule.ProcessRequest (System.Net.HttpListenerRequest request) [0x000a2] in :0 at EnergySmartBridge.Modules.WebServerModule.SendResponse (System.Net.HttpListenerRequest request) [0x00024] in :0 EnergySmartBridge.Modules.WebServerModule: 2024-01-27 13:12:50,304 ERROR: SendResponse System.NullReferenceException: Object reference not set to an instance of an object at EnergySmartBridge.Modules.MQTTModule.PublishWaterHeaterState (EnergySmartBridge.WebService.WaterHeaterInput waterHeater) [0x002ad] in :0 at EnergySmartBridge.Modules.MQTTModule.ProcessRequest (System.Net.HttpListenerRequest request) [0x000a2] in :0 at EnergySmartBridge.Modules.WebServerModule.SendResponse (System.Net.HttpListenerRequest request) [0x00024] in :0

[Boohooligan]

Are you sure the Mqtt server info is correct? Also are you using an up to date HA?

[mefbgil]

Yes, messages are arriving on MQTT. And yes, "2024.1.5" of HA. After checking HA, I'm seeing the sensor show up there as well. I reverted back to my old containers. I'm running HA in docker so not setting this up as an add-on. I'm building my own containers.

[starsoccer]

Yeah it will likely need some tweaks to work as a standalone docker and not an addon. If you make a issue on my repo Ill work with you to get that working