I am trying to send a string to a web device, it connects as it gives an error when unplugged but does not when it is plugged in, i have read lots of articles and tried a lot of the fixes but it will not work. Appreciate any advice.
I need to send this {21,100,0,~} to ip 192.168.0.100 port 2081. Could you suggest why it does not work, i hope i have supplied all i need to help anyone figure it out.
I have defined this at the top
TCPClient client;
byte server[] = { 192, 168, 0, 100 };
const char command[] = "{21,100,0,~}";
i then in my code run this to connect and send.
if (client.connect(server, 2081))
{
client.write((uint8_t *)command, sizeof(command));
client.stop();
}
else
{
Serial.println("connection failed");
}
Have you made sure your router will route this port (2081) from another host such as a laptop on the same network? A lot of times the problem is not on the Particle device, but in the router.
Just to make sure the code processes to that point. That would rule out the Particle device (and you didnât state which device type but Iâm guessing Xenon on an Ethernet Featherwing since you say âunpluggedâ). Are you able to run Wireshark to make sure the packet actually makes it onto the wire?
That is good advise from @ninjatill so I would try that.
You could also try adding a small delay after client.write(...) and before client.stop() in case the connection is getting torn down prematurely. In a perfect world you would use 'client.flush()` but that does nothing right now.
I have tried that and can confirm that it print via serial, I assume the connection is working or it would crash or give an error or something.
I think the issue might be what its sending or how its sending, i need it to send this -> {21,100,0,~} <- as a string in text format, i dont know 100% if my code is right to send that like that as a text format to the ip address.
Also to clear up potential confusion its a particle photon chip and im sending it to a wifi device, i.e that text im trying to send {21,100,0,~} once received by the wifi device does an action. I know the action works when sending via Hercules so i assume its not sending in the correct format?
Using the sizeof() operator you will send the null terminator on your command string. Is the receiving device expecting the null terminator? Can it handle it correctly if not? Just something to consider.
OK. âPhoton on wirelessâ gives some other ideas for trouble shooting. Make sure your wireless allows peer-to-peer communication. Some access points allow you to disable peer-to-peer communication. This is more common in internet cafes or public hot spots so that malicious actors with a wireless device canât communicate with an unsuspecting victimâs device.
The declaration of your command[] looks Ok to my bit of C++ knowledge. But the cast is not something Iâm familiar with. Why are you casting to a uint8_t here: (uint8_t *)command? This example in the docs would lead me to write it a bit different:
Thanks for your reply, as far as im aware p2p is enabled as i can send the command via my laptop on the same network, i send the uint8_t here: (uint8_t *)command? purely as its something i read from another forum post my concern was that it might be recieveing {21,100,0,~} but as a different character set such as ascii or hex, im fairly new so i thought that might be an issue. I it to be send and received as â{21,100,0,~}â.
@tomtom, hex is not a character set, just a numerical representation. The command you want to send is ASCII. Are you saying you need to include the double quotes as part of the message?
hi, sorry i meant in a different format of any kind, in the docs it states you can set an optional base value â(optional): the base in which to print numbers: BIN for binary (base 2), DEC for decimal (base 10), OCT for octal (base 8), HEX for hexadecimal (base 16).â
This is what i was referring to, as for your question no its just the {21,100,0,~}
Ive just re-read your suggestion as i miss read it, ive tried that but i get a " invalid conversion from âconst char*â to âconst uint8_t* {aka const unsigned char*}â [-fpermissive]" when doing that
Yes. You are right, it wonât compile. Like I said, my c++ skills are weak . I tried to get an example going and I think itâs working. Using wireshark, I just couldnât see what the data was on the TCP packet. I donât know if the data isnât received or that I just donât know how to use wireshark. So I attempted to also send the same data via UDP. The UDP packet clearly shows the payload is working.
#include <Particle.h>
TCPClient client;
UDP udpClient;
byte server[] = { 192, 168, 0, 186 };
int tcpPort = 2081;
int udpPort = 2082;
const char command[] = "ZZZ Hello World!";
void setup() {
}
void loop() {
if (client.connect(server, tcpPort))
{
client.write((uint8_t *)command, sizeof(command));
client.stop();
Serial.println("Command Sent TCP.");
}
else
{
Serial.println("connection failed");
}
delay(1000);
//Send again using UDP.
udpClient.begin(2082);
if (udpClient.sendPacket(command, sizeof(command), server, udpPort) < 0) {
Particle.publish("Error");
} else {
Serial.println("Command Sent UDP.");
}
udpClient.stop();
delay(5000);
}
Apparently the 2 TCP packets in the above post, before the UDP packet, are from the connection attempt⌠not sending the payload. Iâm thinking the payload should go on another TCP packet that is never sent by the Photon. Looking at the serial output, the TCP connection returns false every attempt. Only the UPD command gets sent.
I donât know if itâs a bug or not but I canât get TCPClient.connected() to return true. The TCP SYN packet is received and my PC sends back a TCP RST packet. Then the TCPClient.connected() returns false. Every time. I donât know why. Maybe an Elite knows if this is a bug or just my lack of understanding⌠@bko, @ScruffR, @Moors7, @peekay123?
Come to think of it, I suppose you need a TCP server on the other end to receive the packets. Itâs not like UDP which is a, mostly, one-way communication. UDP doesnât care if the packet gets received. TCP requires two peers.
. I tried to get an example going and I think itâs working. Using wireshark, I just couldnât see what the data was on the TCP packet. I donât know if the data isnât received or that I just donât know how to use wireshark. So I attempted to also send the same data via UDP. The UDP packet clearly shows the payload is working.
