Ad blocker detected:
Our software and support is 100% free. This website is not.
You can donate in 2 ways, by turning off your ad blocker or by pressing the Donate button.
************ NOTICE ************
UPDATE YOUR BOOKMARKS!!!
We have an issue that there is no way around as of yet.
I have done all I can to try and prevent this from happening.
We are going to be losing the .com, .org and .de domains.
We have not been able to contact the original author of EventGhost
(the person that owns those domains) to redirect them to the new web server.
I set in motion when we first moved a redirection from the old server to the new server.
I also put in markers so that search engines would see this change and update any pointers
they have. We still have the .net domain for the production site. and the .rocks for the test site.
For the past few months you have been getting redirected to the .net site if you used one of the 3
domains mentioned above. I just wanted to tell everyone so they can make any changes needed.
Does anyone have any ideas or advice on what string/chars to send to the Eventghost UDP listener? I'm running the Broadcast plugin and able to send UDP packets from eventghost to my ESP8266 just fine and it shows up in my serial monitor. However, In my code, I have the ESP8266 setup to reply back to Eventghost using the remote port and IP address that was received from the Eventghost UDP broadcast and can't seem to get any response posted to the logger window. Is there a specific string that needs to be replied back to Evenghost in order for Eventghost to acknowledge this reply and log this event and post it in the logger?
Nevermind. I found the problem within my sketch. It dawned on me when I noticed that the remote Port in the serial monitor was displaying a completely different port every time the reply was sent back to Eventghost. I had setup my sketch(script) to display the remote IP and remote port when it receives a broadcast UDP packet. Once I noticed that the port would change with every broadcast, I constructed my script to only reply to a specific port(the one set within the Eventghost plugin). Initially it was setup to reply to the remote IP and remote port(which would constantly change) that the broadcast originated from. Not really sure why it would constantly change, yet. I better brush back up on UDP protocols again. My best guess is that the port specified for listening within the Eventghost plugin must be the same port specified in the unicast, otherwise the packet will be dropped. Hence the reason it worked immediately once I updated my code to broadcast to that particular port.