Yes I did. Search for A1 and change them all, plus the initial call. It is working for me.
You will have to rewire as well but I’m sure you know that.
The product says on it webpage:
“Does Not Yet Support Communications to the Particle Cloud”
What does this mean? If this gets the Photon on the network, why can’t the cloud be reached?
Connecting to Photon via Ethernet
Because you can’t tell the system firmware to use that application code library for its internal tasks.
Native cloud communication is a system task, not an application task. User applications can only use the dedicated functions to hand parameters to the system which in turn runs it through its own network stack.
There is currently no way to redirect the system to a different network stack than then one in its own bowels - you’d need to fork the system firmware and adapt that.
Thank you @ScruffR for your prompt response.
I do not understand though. The shield comes with TCP client/server examples. So can I use this shield to communicate to my own TCP server on a public IP address?
I thought this thread was no loner alive so I posted a separate post. I will try to delete it.
Particle Cloud communication is a very special kind of communication and has its own security layer. Without feeding the data through that, the Particle cloud will not accept the conversation.
I see. So what can this shield be used for? Just to communicate to another machine on a local hub using a local IP (192.xxx.xxx.xxx)?
I think you are confusing Particle Cloud and internet.
You can connect not only locally but also to the internet but you cannot talk to the Particle Cloud (a very specific target) with this.
Thank you @ScruffR, indeed I was. OK, it is clear now.
In my application, I do not need the Particle Cloud, so this is good news.
Thanks again and sorry for the double post.
Hi @IOTrav, overall your W5500 library has been working great, thanks again for the hard work on that!
However, I have now run into a difference between the standard UDP module and your EthernetUDP module, which is that the former includes methods
leaveMulticast(), while the latter does not.
These methods are used for example in the MDNS library for Photon. I tried looking deeper into this myself to see if I could port the methods over but it led down a rabbit hole leading to
wiced_multicast_join() within the Photon’s socket_hal.cpp which requires a
wiced_wlan_interface() as one parameter. I wasn’t sure where to go from there.
Any ideas for how these methods could be added to EthernetUDP, or more generally how the MDNS library could be used with the W5500?
I think you can do this but you will get better advice over in the WizNet forum: