First, I tested the communication of 2 XBee (series 2) in AT mode and all worked correctly.
Then I changed the Coordinator to API mode and ran the below script while the router was in AT mode. I was successful and received the routers message. However, I can't get the router to be in API mode and send messages to the coordinator. I'm not sure if i can just do simple send command or if I need to specify the address or if the fames have to be formatted.
Each xbee is connected to a PC. I'm using python 3.4.
Coordinator in API mode to receive messages:
Continuously read the serial port and process IO data received from a remote XBee.
from xbee import XBee,ZigBee
import serial
ser = serial.Serial('/dev/...', 9600)
xbee = ZigBee(ser)
while True:
try:
response = xbee.wait_read_frame()
print(response)
except KeyboardInterrupt:
break
ser.close()
Has someone else done this or know of a site that could help me explain how the router in API works? All I want to do is to send messages from the router to the coordinator.
API mode works the same whether the device is configured as coordinator, router or end device. If your router is always sending data to the coordinator, there's no need to run it in API mode -- just keep it in AT mode with DH and DL set to 0. It will automatically send frames to the coordinator containing all data that comes in on the serial port.
If you need to use API mode on the router for some reason, just use the python-xbee library you're already using on the coordinator.
To communicate in API mode, you must send frame.
A frame is compose by a header and a footer.
There is some library to help you communicate in API
http://ftp1.digi.com/support/utilities/digi_apiframes2.htm
this web site show you how to communicate in API
Related
I have a little problem with RPC communication. It works really well without VLANs, but when I add Vlans and configure network with them. I can only connect to the device from a python script, but all RPC communication gives me a timeout error. If the network is only on Unit 0 RPC messages work fine. I work on GNS3 environment, 2 times vSRX 19.2R1.8 One as Firewall, the other in Switch mode.
Could it be a configuration problem?
I can also send configuration of devices
Using the azure-iot-sdk for python I have a program that opens a connection to the IoT Hub and continually listens for direct methods, using the MQTT protocol. This is working as expected. I have a second python program that I invoke from cron hourly, that connects to the IoT Hub and updates the device twin for my device. Again this is using MQTT. Everything is working fine.
However I've come across in the documentation that a device can only have one MQTT connection at a time and the second will drop cause the first to drop. I'm not seeing this, however is what I'm doing unsupported?
Should I have a single program doing both tasks and sharing a single connection?
Yes that is correct, you can't have more than one connection with the same device ID to the IoTHub. Eventually in time you will have inconsistency behaviors and that scenario is unsupported. You should use a single program with a unique device ID doing both tasks.
Depending on the scenario you may want to consider using an iothubowner connection string to do service side operations like manage your IoT hub, and optionally send messages, schedule jobs, invoke direct methods, or send desired property updates to your IoT devices or modules.
I am trying to get a notification (over REST connection) when any host is trying to communicate in my network. I registered for a Packet-in-message change-event-notification that I found in the packet-processing module. when I start listening using my websocket client, I receive nothing!!!!!
I was expecting some notification with each packet-in reaching the controller. am I miss-understanding the use of this module? what is the purpose of this packet-in-message?
Is there a way to get a notification when any host is trying to set a communication with another host (over REST)?
I built my topology in mininet. It contains some openflow switches and hosts. The Opendaylight controller has l2switching, restconf, openflowplugin and dlux features enabled.
Any one have idea when i am sending the messages using the wifi network they are sent but i was not able to receive the same. Means wifi network will send the message but same network will not able to receive the message, on other side if i change my network to mobile data then its working fine.
Always check internet connection availability before running the application for push notification.
GCM works by keeping a long-lived socket open to Google's push notification server. The socket is kept open by sending "heartbeat" messages between the phone and server.
The network state may change and this socket will be broken (because the IP address of the device changes, from 3g to wifi, for example). If the message comes in before the socket is re-established, then the device will not immediately get the message.
The re-connection only happens when the phone notices the socket is broken, which only happens when it tries to send a heartbeat message.
You may check the network available like this:
private boolean isNetworkAvailable() {
ConnectivityManager connectivityManager
= (ConnectivityManager) getSystemService(Context.CONNECTIVITY_SERVICE);
NetworkInfo activeNetworkInfo = connectivityManager.getActiveNetworkInfo();
return activeNetworkInfo != null;
}
Here's where I get my answer: Google Cloud Messaging - messages sometimes not received until network state changed
Live tiles are able to receive push notifications without the associated metro app needing to be running.
However I believe that the app must have run at least once in order for the app to acquire a notification channel and subscribe to a notification server, passing the channel to the server.
My question is -
What happens if the server cuts off the client? If the user turns off their computer I presume the server would start receiving delivery failure errors. The server might then cut off the client.
But what happens when the user turns their computer back on? Is the tile now disconnected until the user starts the app again and it resubscribes with the server for notifications?
Or is there a way for the tile to resubscribe automatically on start up without the app having to run?
The push notifications are not sent directly to the client; they're sent via the Windows Notification service in the cloud. This means your service will be able to just send them. The WNS service will do the right thing with notifications when the machine comes out of sleep / reconnects to the network.
http://msdn.microsoft.com/en-us/library/windows/apps/hh913756.aspx has a overview of the service side of notifications.
It's important to note that the tile channel expires after 30 days, and will need to be (programmatically) renewed. The guidance is that you should renew when the app runs to make sure it doesn't expire.
The only thing I can't seem to locate in the documentation is how many push notifications are queued on the client - I suspect that for a given tag notification, only one is kept.
Maybe another way to think about this is with the bad notification -- e.g a "new items" count. If you push this number while the device is disconnect from the network (off, driven over etc), then your service will succeed in sending the notification, and when that machine reconnects, it will seamlessly see the badge update.
You should handle that in your code that when your clients from the server went offline then you should remove them and disconnect them, the client side will only receive the cached values in the live tiles.
If they went back on, then you should also handle it in your server side to push the new notification data.
Just a quick tip: If you are using WCF as your service, you might want to check the Announcement Service Class there you can handle your clients online/offline scenarios.