I've been using node-red to simulate TCP and RTU slaves on a raspberry pi and a dell gateway. So far, I've managed to get the TCP slave working, but it doesn't seem possible to do it via rs485 on node-red.
Is it possible to use pymodbus running on a raspberry pi connected to a dell gateway via rs485 to simulate a slave device, because the examples provided only specify a serial connection rather than an rs485 connection specifically? If it is possible, please could you recommend an example that I should use from the pymodbus readthedocs examples?
Related
I am currently working on a project that involves communication between a PLC , Raspberry Pi 4 and a BMS (Battery Management System) system on a battery.All three device use RS485 for communication using minimalmodbus via python on the RPI.
The Raspberry pi has a generic CAN/RS485 HAT (similar to this : https://www.waveshare.com/rs485-can-hat.htm)
Currently I am able to communicate with the PLC to receive and send data from the RPI with the PLC as a master and the RPI as a slave.
As per my understanding , in order to read data from the BMS using the Pi, the RPI has to be a master. But in this case, as the RPI is a slave to the PLC, and the PLC cannot be used to read data from the BMS.
I would like to know if it is possible for the RPI to function as a Master to the BMS when being a Slave to the PLC at the same time ?
Assuming that it is possible able to connect another RS 485 HAT to the same RPI and run separate scripts for each HAT.
A couple questions.
TLDR is sending UDP broadcast packets on a Wifi network to allow for discovery of a IoT device (Raspberry PI) a conventional practice?
Long version: I'm working on an IoT project for a class. Based on other IoT devices I've used (a Christmas carol lighting system and music player), we decided to utilize an already working application (https://github.com/balena-os/wifi-connect). The way it works is it runs on the Raspberry PI and hosts a wifi endpoint through the RPI's network card that the user can connect to. Once a user connects to this Wifi endpoint on his/her Iphone, a Wifi selection and password entry page appears on his/her Iphone. The user enters the Wifi/password that the IoT device (Raspberry PI) should connect to. The entered Wifi will then be connected to by the Raspberry PI. The user can then connect to the entered Wifi as well and now both the user's Iphone and Raspberry PI will be connected to the same Wifi network.
We decided to send UDP packets to the broadcast address of the Wifi network from the IoT device, so that users connected to the Wifi (via their Iphones) can "discover" the IoT devices IP address by listening for UDP packets. Once the user discovers the IoT device's IP address, they can send HTTP RESTful API calls to the IoT device. I was wondering if the described process is conventionally used.
# script we are using to send UDP broadcast packets
import socket
import time
server = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT, 1)
server.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
server.settimeout(0.2)
message = b"message"
while True:
server.sendto(message, ('<broadcast>', 16123))
time.sleep(1)
We tried this setup at a public library, using their free public wifi. However, the UDP broadcast packet discovery process failed. UDP broadcast packets were sent out by the IoT device, but were not received by the Iphone. We're wondering if this has something to do with a firewall. We could successfully send UDP broadcast packets from a Macbook (via a python script) to an IOS emulator residing on the same Macbook, such that the source IP address of the packet was the same as the recipient. Is there a firewall rule such that a broadcast packet sent from IP address [A] can be delivered back to IP address [A] but not to IP address [B].
Also, I didn't mess around with the port number, which might have helped if certain ports were disabled by a firewall. I'm not sure. Help is appreciated. We are both relatively new to this.
DNS-SD (RFC6763) is the a fairly common and standardized way to do network discovery. It actually supports both TCP & UDP services. It was originally invented by Apple under the brand name "Bonjour" for printer discovery.
So yes, it is common to use UDP broadcast packets (via DNS-SD) for IoT device discovery on a Wifi network.
I'm trying to send UDP packets over the t-mobile NB-IoT network using AT-commands on a SIM7020E chip. I used the product wiki as reference. The starter version of the sim card I have doesn't support TCP, but I'm planning on using that later if I can succesfully communicate using UDP.
I created a UDP-socket on a Raspberry Pi using "nc -u -l 9999". I set an A-record on my hosting provider to refer dev.mydomain.com to the IP address of the Raspberry Pi. I verified the portforward and A-record settings by sending UDP packets from my laptop on another network using "nc -u dev.mydomain.com 9999" and typing some teststrings, so this all works.
On the 4G chip I use the following AT-commands:
// Check network
AT+CSQ
+CSQ: 21,0
AT+CGREG?
+CGREG: 0,5
AT+COPS?
+COPS: 0,2,"20416",9
AT+CGCONTRDP
+CGCONTRDP: 1,5,"iot.t-mobile.nl","x.x.x.x.255.255.255.0" <-- crossed out my ip
// Create UDP socket
AT+CSOC=1,2,1
+CSOC: 0
// Connect socket 0 to the listening port on the Raspberry Pi
AT+CSOCON=0,9999,"dev.mydomain.com"
OK
// Send "test"
AT+CSOSEND=0,0,"test"
At this point I expect to see "test" appear in the command line on the Raspberry Pi, but nothing happens. In the T-mobile portal it shows a PDP-context is successfully activated.
Also, setting the APN manually with AT*MCGDEFCONT="IP","iot.t-mobile.nl","username","password" doesn't work.
Did you work this out Hans? I was plodding along with a SIM7020E following https://www.waveshare.com/wiki/Pico-SIM7020E-NB-IoT code examples. Was successfully sending HTTP GETS to a server (without having to use micropython's wretched urequests lib) via the CHTTPCREATE/CHTTPCON/CHTTPSEND AT cmds, that seem to be be able to send packets over LTE to a server without specifying TCP/UDP etc or using a socket. Maybe give it a try?
Sadly I got the bright idea of trying an 'AT+POWD=1' cmd over the uart (was supposed to power the 7020E down) & now the module now does nothing but echo AT cmds (still auto connects to the LTE network & slow flashes the network led, just won't do anything else.) Real shame, nice little module otherwise.
I'm working on a project where I need two raspberry pis to communicate and the ethernet port is not free, I'm not allowed to make any changes to the GPIO pins, and I'm forced to use the USB port due to hardware considerations. Is it possible for them to communicate using a direct USB cable, or perhaps using two USB-RS232 cables?
Thanks!
Siddharth
I would use the TTL serial pins on the GIO header. See https://elinux.org/images/1/13/Adafruit-connection.jpg
You could create your own simple null modem serial cable - consisting of 3 jumper cables.
Connect pins
6 <--> 6
8 <--> 10
10 <--> 8
If you can't use the GPIO header - you can do a USB to USB connection using USBNET. http://www.linux-usb.org/usbnet/
Is it possible for them to communicate using a direct USB cable, or perhaps using two USB-RS232 cables?
You fail to mention exactly which Raspberry Pi version(s) you are using.
Only the Raspberry PI Zero can be used as a USB Gadget.
Since USB is a master-slave(s) interface & protocol, you cannot simply connect two Raspberry PI 1/2/3 boards together using USB, because that would be a master-to-master connection.
If you look hard enough for a (passive) USB Type A (male) to Type A (male) cable, you can find them, but it's a bogus connection that will not work.
There are active USB host-to-host cables (which contain a shared gadget), but support can be an issue.
You could connect a Raspberry PI 1/2/3 to a Raspberry PI Zero by USB, so long as the Zero's USB port was configured as a USB ACM CDC gadget.
However one simple solution is your alternative of installing USB-to-RS232 adapters to each board. A null-modem cable of three wires would suffice unless you needed hardware flow-control.
An alternative solution is installing USB-to-Ethernet adapters to each board (with static IP addresses, i.e. an ad-hoc connection). This approach provides a much faster connection than an RS-232 link, and is easily utilized by applications.
I wanna catch probe requests of mobile devices that are not connected to a network using monitor mode on Raspberry pi 3. I am using Raspbian OS. I used "Wifite" command but it only shows the mac addresses of access points and not of the non connected mobile device. I am a beginner in networking and Raspberry pi. Kindly guide me which commands should I use for this purpose?
You might try looking into sniff-probes.
It switches WiFi channels every two seconds and captures incoming packets using tcpdump.