Honeywell integration stops working with blacklist error

now getting this in my event logs…

debug event from: Office Temp/Humidity Sensor, value: 72, source: DEVICE, description: catchall: 0104 0402 01 01 0140 00 E2BA 00 00 0000 01 01 000000295509

4b1bceb3-4c72-4584-a72d-3d132a3a4fff ‎3‎:‎15‎:‎47‎ ‎PM: debug refresh temperature, humidity, and battery

344b2007-0083-42c9-9cc5-44910f416cb7 ‎3‎:‎15‎:‎47‎ ‎PM: error java.lang.SecurityException: Endpoint https://www.mytotalconnectcomfort.com/portal is blacklisted. @ line 860

344b2007-0083-42c9-9cc5-44910f416cb7 ‎3‎:‎15‎:‎47‎ ‎PM: debug Executing ‘login’

344b2007-0083-42c9-9cc5-44910f416cb7 ‎3‎:‎15‎:‎47‎ ‎PM: debug units = F

344b2007-0083-42c9-9cc5-44910f416cb7 ‎3‎:‎15‎:‎47‎ ‎PM: debug Executing ‘refresh’

1897b52e-9b3f-4f65-a913-6d6cb2e0b0a6 ‎3‎:‎15‎:‎47‎ ‎PM: error java.lang.SecurityException: Endpoint https://www.mytotalconnectcomfort.com/portal is blacklisted. @ line 860

1897b52e-9b3f-4f65-a913-6d6cb2e0b0a6 ‎3‎:‎15‎:‎37‎ ‎PM: debug Executing ‘login’

1897b52e-9b3f-4f65-a913-6d6cb2e0b0a6 ‎3‎:‎15‎:‎37‎ ‎u: debug units = F

1897b52e-9b3f-4f65-a913-6d6cb2e0b0a6 ‎3‎:‎15‎:‎37‎ ‎PM: debug Executing ‘refresh’

000fdb3f-26ab-4586-94a5-3d478ab26acf ‎3‎:‎15‎:‎45‎ ‎PM: debug updating stateID

it think it is becasuse occasionaly when things are slow it is not returning in the 20 secs (it use to have the 20 sec timeout message) and thus they are adding it to some list… At least it looks like the list clears after 15 minutes or so.

however I am getting timeouts in the logs also on stock devices such as my gd00 garage door.

I see you updated your post, so hopefully it’s just typical ST slowness/weirdness, not true blacklisting.

Also, it’s possible that Honeywell is blocking you, not ST. I know several users had issues with Honeywell blocking them for making too many calls, although I think the error would be different. Honeywell really doesn’t want you to access their API through non-traditional channels.

I was able to refresh my thermostats just now too.

f879d4d8-a635-428d-b08d-81a13c401233 3:41:00 PM: debug Request was successful, 200
f879d4d8-a635-428d-b08d-81a13c401233 3:40:59 PM: debug https://mytotalconnectcomfort.com/portal/Device/CheckDataSession/(device info removed)

no Honeywell block would not cause that error message you just get a unauthorized response… that message has to come from smartthings … in addition that is the line in the device type hitting Honeywell which also reinforces that smartthings is doing it.

its intermittent for me… one or two times I get that error message on login. then next time it works… thus my synopsis that the black list is being cleared periodically.

it also appears that it may be a global blacklist … not just from your devices as suddenly it will be blacklisted for me even though it didn’t have a recent hit to it… Let your logs run for a half hour or more and take a look.

I am getting around it if that is the case… there is more than one way to skin a cat.

bas**##*sI tried to change to ip… but that doesn’t work either, also proves it is smartthings as line number changed as I added comments.

We are not blacklisting anything. The error message could be more descriptive, but this error is thrown when the endpoint does not exist. Which device type are you using?

2 Likes

Now now, everyone knows for a fact that whenever something goes wrong it’s because ST is up to no good… Don’t deny it! We know you did it! Just because there was no video doesn’t mean it didn’t happen!

1 Like

this is the Honeywell total connect device type… it is custom… written by someone else modified by me… if it is not a blacklist than either you are having connectivity issues in your servers or your dns servers are failing lookups… because this is running in the cloud… or Honeywell could be down which I doubt as their regular app is working fine and they have been very very reliable.

I was maintaining a device type for honeywell for a few months and I abandoned the effort because honeywell now expressly forbids accessing their cloud services in this way. Here is my post from March 2015.

that may be so… but that is not the response you get … you get an unauthorized response from the server… not nothing… and if the device type is written correctly they cannot tell you are not just using the web interface.

But they can and do rate limit based on IP and all of the SmartThing’s users are coming from the same pool of IP addresses. Are you able to access the service now? Others are reporting that it is working for them.

yes you are correct. hopefully they wont block your ips yes it is working ok again… no errors I can see in the logs… wonder if your servers are too busy around sunset… I am also getting intermittent timeout errors in basically stock device types, or at least copied from stock with only minor changes…

1 zwave garage opener and the other is a fan switch again only intermittantly

Let’s try and keep this thread constructive and stick to the issue at hand.