Webhooks, the biggest mystery

Sure, but this isn’t telling anybody how you got to it, so 20 posts later and no other user with the same issue reading this would know how to generally debug this. This is your opportunity to elaborate and really help others. How did you narrow it down?

Yet you didn’t follow one of the easiest ways to get more info: Listening for events. Or maybe you did and didn’t tell anybody here.

Petro told you exactly what to do a few posts before that:

Events have a type, like a category, grouping or class. webhook is one of these. In that console, you listen to an event type.

Sorry, I will elaborate.

I tried listening for events, I did subscribe to webhook, but I didn’t get anything, literally. I was staring at the “events” section, but it didn’t return anything, meanwhile in the logs I was spammed by the same vague warning about webhook, nothing else.

In the end, I found the cause by disabling all integrations and all the add-ons in my HA. Then one-by-one, I started enabling each add-on and integration until the warning reappeared. This way, I was able to confirm it was the motion eye add-on. I removed the integration and uninstalled the add-on, basically started from scratch with them, with the new config. I know, maybe it is crude, but it allowed me to find out what was causing it.

Conclusion: I did not find event listener fit for purpose, in this case.

Excuse me, but how was I supposed to know that it is so easy? I didn’t know until @petro told me to use it. In the end it was useless to me and I had to find the other way…

I appreciate all the help, but I think this shouldn’t be the first place to look about how to solve basic problems with HA.

In general, before I ask for help here, I always check the documentation first. The problem is I can’t find a section about basic problem-solving, it’s all over the place, when it comes to teaching you how to gather information about issues.

For example, this isn’t really helpful. It explains what Event listener does, but it doesn’t explain how to use it. And honestly, based on this experience, I think it is possible that I still don’t know how to use it properly…

When you search the documentation for webhook, the only result you get is this information about webhook trigger.

Sorry, but this is from a perspective of a noob, which I still am.

Again, thanks for all the help.

1 Like

You simply put the event type and press start listening, if you don’t get events, then the events aren’t occurring. Events are always going to be ambigous because they are something that happens at a point in time, without knowing what the event is, it’ll be hard to track down. In your case, it turns out the webhook was being completely blocked.

Anyways, for future comers, if the IP matches your HA instance, set webhook logging to debug to find it’s source. If it’s not coming from your HA IP, then it should be easier to identify because the IP will point at the device. The correction will happen on the device, not in HA.

logger:
  default: info
  logs:
    homeassistant.components.webhook: debug
1 Like

Someone offered the same ‘debug’ option, but still,that log info is quite useless….actually it didn’t help at all

2022-01-14 12:19:24 DEBUG (MainThread) [homeassistant.components.webhook] Handling webhook POST payload for 941e8496316899fae46420bfff728ba0c4dbad924845952895f935679aacb115c02535abc
1 Like

what’s directly in front of that?

The goal is to find the source of the error. So you’ll have the error, then sometime before that, the debug webhook, then something before that which is creating the webhook. I’m not going to be able to tell everyone how to properly debug things, at some point you’ll actually have to troubleshoot.

I agree, from the perspective of average user this DEBUG is meaningless…

Nothing…just repeating the same debug message over and over again…
(and occasional some other message)

Luckely this was a quite fresh system, with hardly anything setup yet, so it didn’t take me long…

Then you have to enable debug on the entire system because the integration causing the websocket call isn’t outputting anything around it.

I understand your frustration, but you have to understand what you’re getting youreself into when you use websockets. You’re upset about not knowing who’s talking to HA. For example, someone plowed my driveway the other day. I have no idea who did it, I don’t pay anyone to do it, it was clearly a mistake. They screwed up my lawn. How would you debug that situation with the information you have? You can’t. Websockets are like that. As a receiver of said websocket, the most information you can get is where it comes from and what time. The rest is up to you to figure it out by knowing whats in your system.

Edit: this was probably a bad analogy. Point is, there isn’t a way to get more info. You’ll have to put in the legwork.

Obviously more a feature request than anything but maybe webhooks should log the integration that called it by using the ID? At some point in time that ID was registered unless it got made up somehow. In the case of mobile app its all stored in .storage I think users are asking to have less hoops to jump through to get to the cause. Its like an integration saying the vacuum didnt work but fails to list the entity ID when you have more than 1 vacuum.

I fully agree with the above because at the moment it is more like a guesswork.

I don’t mind debugging stuff when it breaks, but at least I expect to find meaningful information when doing just that.

That’s not how webhooks work. You post information to a url and home assistant reacts in it. It’s not a “call”. So the information your asking for doesn’t exist unless the person who creates the webhook decides to add that information into said webhook.

See

Edit: and even if the integration information was in the webhook… it still wouldn’t solve the issue in this thread because home assistant rejects the unknown webhook and doesn’t read the potential malicious data. Hopefully this spells the picture a little more.

While you can agree with him that doesn’t mean it’s possible…

mobile_app could be a unique case here because the user does not create the webhook ID, thats generated by HA core and then sent to the app during onboarding IIRC. The issue becomes noticeable if for example you remove the integration for your device and then continued using the app because the frontend will continue to work as that uses a token which doesnt get removed in this case. The error will show up anytime the app tries to send sensor updates or anything else that we use for the webhook. So at least in this case where HA provided it, there could be something stored to maintain the old IDs. However given the user removed the integration HA would have to maintain that list of core generated IDs. its not about reading the webhook data here but more about HA checking to see if the ID was previously used during the rejection. Of course if it was never registered then it wouldnt be an issue but in the case of “nothing changes and now I see the error” it could be helpful to guide the user to the mistake. I cant speak for the actual integration/add-on in question but I think there are other integrations that also register webhooks where this could work.

core/homeassistant/components/mobile_app at b273c37d2b93d39d47868781d232ac5ef4c552e7 · home-assistant/core · GitHubinit.py#L94

core/homeassistant/components/webhook at b273c37d2b93d39d47868781d232ac5ef4c552e7 · home-assistant/core · GitHubinit.py#L29-L51

Obviously as a contributor for the android app I tend to see this issue a lot so I always know where its coming from :stuck_out_tongue:

2 Likes

That is what happened to me, that is (at least, partially)
I want the user to use the app, but I disabled many of the mobile entities (like battery and location), as that info is currently unwanted; I only want the user to access HA and not the other way around :wink:

Then don’t use the app and have them use a browser :wink:

Some users decided to do that, some use the app…
Anyway, I figured it out, it is no problem anymore :wink:
But thanks anyway :+1: