Trigger Webhook widget to PUT data to other Blynk Project

@psoro Post your Webhook screenshot, Full URL (no need to hide Auth for Local Server), source and target vPin particulars (what are you trying to send to what).

Oh, wait… I think I see… I tried something similar. You can not use another button on the same pin (as the Webhook) as all that happens is the buttons state is sent

If I am understanding correctly, what you need to do is set the “activation” button to a different vPin, and use a corrisponding BLYNK_WRITE() function to call the Webhook Widget’s vPin with whatever data you want to send via Blynk.virtualWrite() and then in the Webhook widget, use the /pin/ method.

No not code free, and thus similar to the Bridge method :stuck_out_tongue: but it works.

And don’t forget the port in the URL… it is essential from my tests, even when everything is inside the network.

1 Like

What is your local server version?
Probably @Gunner is right. Support multiple widgets on the same pins is very new feature, so it wasn’t tested for all possible cases yet :slight_smile: .

Hi @Gunner, please, see below:
Sender:

Testing the widget:

Receiver:

It works ONLY doing the test, I have added a Button at the same pin at the sender but it does nothing.

@Dmitriy, I’m using last server release.

That will not work… at least it doesn’t for me. The button state on the same vPin overrides your webhook payload, but since you are not using the /pin/ you will not even see that result.

But if you do as I mentioned above, then it shouild work.

Mmm…but, in that case, I shouldn’t had success using the Cloud Server and, doing the same thing the result was ok.
Once I pressed the button the info was sent to the other project…

I’m confused right now…:confounded:

Cloud and Local servers are a bit different :wink: and as @Dmitriy said… shared vPins not really all that tested in every aspect.

That’s my current state of normal… thanks for the company :smile:

:wink:

But wouldn’t this kinda be the same thing as using a button on the same pin/multiple widgets on same pin?

Also didn’t you say

Maybe I am misunderstanding you, but that sounds like you were able to do it without code/script modification?

Not quite the same, I was trying to use a new button to instigate transfer from a different data source … that obviously will not work without code, as the new button’s state overrides the intended data source.

And on that note, NO, I didn’t “modify” any code (AKA compile and upload) as I already had a running sketch, so I simply added the Webhook widget, assigned it to an existing display’s vPin and pointed it via the URL to another added Display on another project.

In fact, perhaps becasue I didn’t modify my existing sketch, and thus didn’t have any corresponding BLYNK_WRITE() for when I tested an added button on same vPin as the Webhook… that might have been a contributing issue?

I have done several tests, please, see below:

Same projects at Local and Blynk Server:

-Cloud Sender & Receiver:

Sender:

Receiver:

WebHook settings:

It works properly

-Local Sender & Receiver:

Sender:

Receiver:

WebHook settings:

https://public-ip:9443/token/update/v1?value=/pin/

It doesn’t work…

The only differences are the https: at the settings and the use of the port. Without the “s” the test does not even work…

Have you tried using the Hardware port (8080)?

Will the same URL work in a browser (replacing the /pin/ with a test value of course).

Hmmm… OK, I tested the same thing on my end, using Local Server, inside network, and it worked perfectly… without even any devices connected.

Note: I am using http and port 8080

Slider and Webhook on V0 (transmitter) Gauge on V0 (receiver)

http://10.10.3.13:8080/b144288cf684402b90303a9d84253a3f/update/v0?value=/pin/

To closer match your settings, it even worked when I switched the receiver vPin to V1… and adjusted the URL accordingly.

Dear @Gunner., @Toro_Blanco and @Dmitriy
Now it’s working properly even at Local Server… I was blind trying to use my public IP when obviously, the local IP is enough…:man_facepalming:
I’m really sorry for wasting your time…
Many thanks to all of you for your help and all the test you did…

2 Likes

It is usually the littlest thing that trips us up :stuck_out_tongue: The public IP might still work with proper port and forwarding, but if not needed outside the network then why bother.

1 Like