? What does that mean?
FYI no issues here. I also tried re-setting it up and it worked fine. Are you sure it’s not a network issue? If you go to https://rheem.clearblade.com in a browser on the same network what happens?
1 Like
I need to re-install it again and I'll get a screenshot. But what I mean by that is in the number of run time and percentage in the logs section. It would easily use up upwards of 80% to 90% of count and execution percentage.
Edit: I tried installing the app again, but since I can't authenticate to Econet it doesn't create the driver and the rest of the setup. I think I can get it by re-installing and older backup. But I'll do that tomorrow probably.
If I go to that URL on my browser it times out. Ping and traceroute yield the same results. So I can only assume that they may have banned my IP. Which wouldn't make sense that the phone app for Econet still works. That should be blocked too, shouldn't it? Correct me if I'm wrong, but from what I gather on this integration code it just "spoofs" Econet in thinking a Apple/Android device is making the API calls?
That link works for me. So this is pretty likely your issue.
But are you on the wireless network with your phone, or are you using 4G/cell network? Try the same clearblade link above in a mobile browser with your phone's wifi turned off?
And you don't have any adblock, parental blocks, or similar blocking rules in your router? PiHole on your network? Flood protection or anything like that active in router? Devices on blacklist in router security?
I had some time to play with it this evening. It does appear that they blocked my IP address from being able to make request to that service. I forced a new IP from my ISP and am now able to connect.
However, that begs the question as to why I was blocked?
Interesting. No idea. I probably did more weird things with their api than anyone when I built this. I’ve never been blocked. Also weird that they’d block your ip and not just disable your username...
I hit the API pretty hard with some switching and testing sometimes and have never seen throttling like Honeywell does. That one day I was trying to figure out the modes and vacation mode and all that from upthread, I must have done 50 or more commands by both Hubitat and the phone app in 30 minutes.
Was it you, or did you maybe get caught up in a general IP block? I know for a while (until we ran into this exact issue) on a forum I moderated that we would block IP ranges (like all the 207.182.217.xxx) from certain regions, or certain providers that were spamming the forum. That caught some regular users in with the spambots. So we had to do some more sophisticated blocking and exact IP banning.
So maybe you didn't do anything?
100% not from something I did. I'm pretty sure it was something similar to what you mentioned. Either a CIDR range that my old IP fell into got blocked or at some point I inherited and IP that was blocked for whatever reason.
I'm leaning towards the latter, since Clearblade is an offering that Rheem is using they probably have some general IP/Spam protection that they share. Meaning perhaps somebody was spamming a Clearblade endpoint for some other API and it got banned across all their API endpoints and then I got this IP.
I don't really control my water heater from Hubitat, it's just a nice to have. So I may have been having this issue for over a year. I only noticed when I was cleaning house and re-writing some rules last week because the app usage was so high. Which makes sense now because the device/app stats was counting however long it took the API request to time out.
1 Like
@dman2306
I have been using this integration for years (since you rewrote it and I bailed from mine).
Anyways my heat pump water heater started leaking after only 5 years and I replaced it today under warranty.
Since I got the new water hearer up and running I am getting MQTT errors on the device.
dev:14572021-03-19 10:20:22.864 pm warnLost connection to MQTT, retrying in 15 seconds
dev:14572021-03-19 10:20:06.847 pm warnLost connection to MQTT, retrying in 15 seconds
dev:14572021-03-19 10:19:50.808 pm warnLost connection to MQTT, retrying in 15 seconds
dev:14572021-03-19 10:19:34.761 pm warnLost connection to MQTT, retrying in 15 seconds
dev:14572021-03-19 10:19:18.728 pm warnLost connection to MQTT, retrying in 15 seconds
Sometimes I get this error:
dev:14572021-03-19 10:20:52.061 pm errorNot connected to MQTT, reconnecting and queuing command
Do you have any idea why this new device is having these issues?
I can control it just fine via the Rheem app.
The Rheem EcoNET Integration App does not return errors. Everything there looks good.
Did you rerun the app and it created a new device and go rid of the old? If you click the initialize button does it give a more useful error? Trying to figure out why it disconnected in the first place.
I reran the app after I connected the water heater to EcoNET. The app found it and at first I kept both water heaters selected so I could move my automations over to the new water heater. Once I had everything moved over I reran the app and deselected the old water heater. The app removed the old water heater device. Then I removed the old water heater from the EcoNet app (phone) and then reran the Hubitat App and the old water heater was no longer in the list.
I have always gotten the mqtt errors with the new water heater. Clicking initialize doesn't provide any new information, just adds another mqtt error.
@dman2306
I am doing some debugging to get to the bottom of this. I added some debug to tell me what the error is that is being returned and I get this:
Invalid client ID (2)
I have printed the client ID that it is using (don't want to post it here) but how do I know what it should be? Should it be returned from the initialization in the App? If so, I do not see anything that matches in the debug of the app.
@dman2306
Soo... I played around a bit and hardcoded the Client ID.
interfaces.mqtt.connect(apiUrl, "012345678919", parent.getAccessToken(), systemKey, cleanSession: false)
This seems to be working and I can control the water heater. For now I will leave it like this if you have any thoughts let me know.
Oh I realize that your getting the client id from the Hubitat hub ID. Maybe it is too big or something??
Interesting. That code has been that way for a while.
Out of curiosity, if you keep it the same length but just change up one character or something like that, does it work? I'm just wondering if something about adding/removing devices screwed up the client ID. The client ID has to be unique for each of us which is why I went with the hub id.
I will have to give it a try.
I am not great with Groovy but I was thinking about using a portion of the HUB ID
@dman2306
Ok, so I changed the App so that it returns the HubID without the -'s.
def getClientId() {
return getHubUID().toString().replaceAll("-","")
}
This seems to be working for me.
Ok, I did some more digging and found some strange spaces and different naming in the modes.
So in the parent I now have this:
def translateThermostatMode(mode) {
mode = mode.toUpperCase()
switch (mode) {
case "ENERGY SAVING":
case "ENERGY SAVER":
case "ENERGYSAVER":
return "auto"
case "HIGH DEMAND":
case "HIGHDEMAND":
case "PERFORMANCE":
return "emergency heat"
case "HEAT PUMP":
case "HEATPUMP":
case "HEAT PUMP ONLY":
case "HEATPUMPONLY":
case "HEAT PUMP ONLY ":
case "ELECTRIC":
case "ELECTRIC MODE":
case "GAS":
case "VACATION":
return "heat"
case "OFF":
return "off"
}
}
And in the device I have this:
if (payload."@MODE" != null) { if (!payload."@MODE".toString().isInteger()) { device.sendEvent(name: "thermostatMode", value: parent.translateThermostatMode(payload."@MODE".status.replaceAll("\\s",""))) device.sendEvent(name: "waterHeaterMode", value: payload."@MODE".status) } else { def mode = translateEnumToWaterHeaderMode(payload."@MODE") device.sendEvent(name: "thermostatMode", value: parent.translateThermostatMode(mode)) device.sendEvent(name: "waterHeaterMode", value: mode) } }
I just implemented this impressive app (thank you @dman2306!) and am running into the same MQTT warning messages as @brianspranger - every 15 seconds.
I can't quite tell from the last few entries in the thread how or if you guys resolved this.
I am too actually. Been meaning to post about it. It worked fine for quite a while too.
Hmm, I haven't seen any errors.
