I have my RPi 3 connected to the internet through an ethernet connection. But I keep receiving these messages on the LogCat.
W/GooglePlayServicesUtil: Google Play services out of date. Requires 11910000 but found 11745330
W/FA: Service connection failed: ConnectionResult{statusCode=SERVICE_VERSION_UPDATE_REQUIRED, resolution=null, message=null}
E/FA: Discarding data. Failed to send event to service
W/FirebaseInstanceId: No response
E/FirebaseInstanceId: Token retrieval failed: TIMEOUT
W/FirebaseInstanceId: No response
E/FirebaseInstanceId: Token retrieval failed: TIMEOUT
W/FirebaseInstanceId: No response
E/FirebaseInstanceId: Token retrieval failed: TIMEOUT
However, firebase cloud messaging works perfectly fine on DP6. Please advice.
The release notes page for Android Things indicates the version of Play Services available for each release of the OS. Developer Preview 6 (and 6.1) includes Play Services version 11.6.0, however it looks like you might be trying to use the latest (11.8.0) client library in your app. The client library version(s) in your build.gradle file must be equal to or lower than the version on the system you are using.
Related
I have an existing application which was running on solace jar v7.1.2 execute in pub/sub mode. Now we have upgraded to v10.1.1 and as part of implementing DR setup(Disaster Recovery), I have added one more host in the configuration with comma separated.
The application could connect to the primary host successfully, but during the switch-over, (ie from primary to DR) the application had failed to connect and i have received the below error. It connects to DR host if I restart my application.
com.solacesystems.jcsmp.JCSMPErrorResponseException: 400: Unknown Flow Name [Subcode:55]
at com.solacesystems.jcsmp.impl.flow.PubFlowManager.doPubAssuredCtrl(PubFlowManager.java:266)
at com.solacesystems.jcsmp.impl.flow.PubFlowManager.notifyReconnected(PubFlowManager.java:452)
at com.solacesystems.jcsmp.protocol.impl.TcpClientChannel$ClientChannelReconnect.call(TcpClientChannel.java:2097)
... 5 more
|EAI-000376|||ERROR| |EAI-000376 JMS Exception occurred, Description: `Error sending message - unknown flow name ((JCSMPTransportException)
Need help to understand if we need to have some configuration to do the reconnect to the DR host for a smooth switch over.
In Solace JMS API versions earlier than 7.1.2.226, any sessions on which the clients have published Guaranteed messages will be destroyed after a DR switch‑over. To indicate the disconnect and loss of publisher flow the JMS API will generate this exception. Upon receiving these exceptions, the client application should create a new session. After a new session is established, the client application can republish any Guaranteed messages that had been sent but not acked on the previous session, as these message might not have been persisted and replicated.
However, this behavior was improved in version 7.1.2.226 and later so that the API handles this transparently. It is no longer required to implement code to catch this exception. Can you please verify that the application is not using an API earlier 7.1.2.226? This can be done by enabling debug-level logs.
As Alexandra pointed out, when using guaranteed messaging, as of version 7.1.2 the Solace JMS API guarantees delivery even in the case of failover. It is normal to receive INFO-level log messages that say "Error Response (400) - Unknown Flow Name", this does not indicate a problem, but exceptions (with stack traces) are a problem and indicate that delivery is not guaranteed.
Background: if the connection between the client and the broker (on the Solace server) is terminated unexpectedly, the broker maintains the flow state — but only for three minutes. The state is also copied to the HA mate broker to support failover (but not to the replication mate). If the client reconnects within three minutes, it can resume where it left off. If it reconnects after three minutes, the server will respond with the following (which will be echoed to the logs):
2019-01-04 10:00:59,999 INFO [com.solacesystems.jcsmp.impl.flow.PubFlowManager] (Context_2_Thread_reconnect_service) Error Response (400) - Unknown Flow Name
2019-01-04 10:00:59,999 INFO [com.solacesystems.jcsmp.impl.PubADManager] (Context_2_Thread_reconnect_service) Unknown Publisher Flow (flowId=36) recovered: 1 messages renumbered and resent (lastMessageIdSent =0)
That's okay: the client JMS library will automatically resend whatever messages are necessary, so guaranteed messaging is still guaranteed.
Also, just to confirm, the jar name indicates the version, so sol-jms-10.1.1.jar uses version 10.1.1.
I am using Google IOT core with mongoose os. I wanted to update device connection status to firestore. But i am unable to find event which reports mqtt connection status to pub/sub like when device disconnects or reconnect i.e if device is offline or not.
I am stuck on this problem for days.Any help will be appreciated
Update
As #devunwired mentioned in this response it is now possible to monitor Stackdriver logs for disconnect events. You must have at a minimum enabled INFO level logging on your project in IoT Core > Registries > [your registry] > Edit Registry > Select "Info" log level > Click save.
Original Response
There are a few values you can look at that are tracked in device configuration metadata that you could use to know when a device last was online:
Last Configuration Send time - sent anytime your device connects /
configuration is posted
Last Event Time - Last time an event was sent from the device
Last State Time - Last time state was sent from the device
Last Heartbeat time - Last time MQTT heartbeat was sent
To get you started, here is an example using API explorer that you can fill-in with your project ID, region, registry, and device to query for a specific device's metadata.
For 1...3 you have control over these through device manager and by publishing data. MQTT heartbeat is updated if your device sends an MQTT_PINGREQ message during the "ping period" without other messages getting sent.
At any rate, you could use any of these update time values to see the last time a device was online / functioning. You could query the states of your devices after listing the devices in a registry and could update a Firebase RTDB periodically if that's how you want to report (e.g. using AppEngine TaskQueue). Note that you also just can get these "last connected" values from the Google Cloud Console.
It was said before but we don't have an event for disconnect, just configuration ack, which generally is the connection event. If you want to share state between a device and the device manager, use state messages.
Unfortunately, there's no built in way to do this right now as there aren't events on this state.
However, you could implement a hack by sending a message on connect/disconnect from the device that you have a Cloud Function subscribed to the Pub/Sub topic listening for. It's not perfect as it would fail in the case where the device disconnected unexpectedly.
There currently is no way to do this, that i've been able to find (a year later after this original post). I posted a question here on SO regarding this as well, with more details and link to example code I had to use for handling this:
Google Core IoT Device Offline Event or Connection Status
The AWS IoT platform publishes messages on a special MQTT topic (prefixed with $aws) when your device connects/disconnects. You can easily use these to monitor these events - however, you should be aware that the MQTT protocol is designed to be robust to a poor networking conditions and the broker on the AWS side probably doesn't think it's a bit deal to disconnect a client. The broker expects that the client will just reconnect and queue messages for a moment during that process (which can be a big deal on a microcontroller).
All that being said, the AWS topics you would watch are:
$aws/events/presence/connected/{clientId}
and
$aws/events/presence/disconnected/{clientId}
and the documentation for these (and other) lifecycle events are located: https://docs.aws.amazon.com/iot/latest/developerguide/life-cycle-events.html
I have a PC and an iOS device. the iOS device is using alljoyn 15.04 and the PC is using alljoyn 15.09. Both implement the same secure interface. We have secure signals as a part of this.
Our strategy includes joining a peer's session as soon as we discover them, then forcing authentication by calling a method on the remote device - using auth mechamism: ALLJOYN_ECDHE_PSK
This all works great!
Now, I can send a secure signal just fine from one ios device from another.
I can also send a secure signal from the iOS device to the PC just fine.
The PC can send a secure signal to another PC, but it cannot send a secure signal to the iOS client
We've compared everything - session options, interface names/options, bus connection options, etc. and everything is the same. Then I found this error in the alljoyn log on the iOS side:
145.449 ****** ERROR ALLJOYN iodisp2_2 .../src/Message_Parse.cc:1078 | Failed to read message on :wYxt8HAP.73: ER_OS_ERROR
I have no idea what to do about this. Can someone help?
I was hoping to not run into any lower level bugs like this with alljoyn. Dang.
Thanks for any help!
This error can occur if you are trying to send a secure signal out on session 0 (sessionless) instead of a valid hosted session. This is because the other end cannot decrypt the signal with your group key for the session. If you are hosting the session then try sending the signal out on ajn::SESSION_ID_ALL_HOSTED and see if that works.
My incoming calls are constantly getting disconnected while it's ringing in (at least 3 times out 10 times)
The below is the log message when this happens.
(I'm using SinchRTC 3.4.1)
(SINLogSeverityTrace log)
REQUEST 3: Request PUT
https://sandbox.sinch.com/V1/Session{"ApplicationKey”:”My
ApplicationKey”,”CallStatistics":{"AudioLevelsDescription":["Timestamp","AudioInputLevel","AudioOutputLevel"],"AudioLevelsSamples":[],"Codecs":[],"RTCPDescription":["Timestamp","PacketsSent","PacketsReceived","PacketsLost","RTTMs","JitterReceivedMs"],"RTCPSamples":[],"RTCPTimestampBase":"1425452945396","RTCPTimestampNormalization":true,"ReportVersion":"2"},"CallTime":"/Date(1425452945396)/","ConnectionInfo":{"Host":"","Port":0,"Protocol":"","Type":""},"DeviceInformation":{"ModelId":"iPhone5,2","ModelName":"","OSName":"iOS","OSVersion":"8.3","PerformanceCharacteristics":"highend","SDKPlatform":"iOS","SDKPlatformVersion":"3.4.1"},"Domain":"","Duration":"0","FromId”:”MyFromId”,”Headers":{"ph":"{\"SIN\":\"Test
SIN call
header\"}\n"},"InstanceId":"98f61bf2-4439-41a5-ac78-a286f3d3eed4","MXPEventLog":{"Events":[["OUT","SENDING","2DE4D14E-5470-41C5-9309-BF942B948405","1425452945479","0","ACK","","{\"channel\":\"0b1ca3d2-94e6-4e65-9834-6d260abb310dS\"}"],["OUT","SENDING","2DE4D14E-5470-41C5-9309-BF942B948405","1425452945494","0","PEEREVENT","","{\"channel\":\"0b1ca3d2-94e6-4e65-9834-6d260abb310dS\"}"],["OUT","SENDING","2DE4D14E-5470-41C5-9309-BF942B948405","1425452945616","0","PEEREVENT","","{\"channel\":\"0b1ca3d2-94e6-4e65-9834-6d260abb310dS\"}"],["ERROR","","2DE4D14E-5470-41C5-9309-BF942B948405","1425452945662","{\"reason\":\"Failed
to decode message
transport\"}"],["ERROR","","2DE4D14E-5470-41C5-9309-BF942B948405","1425452945662","{\"reason\":\"Failed
to decode message
transport\"}"],["OUT","SENDING","2DE4D14E-5470-41C5-9309-BF942B948405","1425452945662","0","ERROR","{\"error\":\"Failed
to decode message
transport\"}","{\"channel\":\"0b1ca3d2-94e6-4e65-9834-6d260abb310dS\"}"]],"Version":"2"},"Outbound":false,"Result":"4","SessionId":"2DE4D14E-5470-41C5-9309-BF942B948405","SetupDuration":"0","Signature":"3+cqz4D6N9dpwS8w9mxAz7gW3oQ=","ToId”:”My
ToId”,”UserId”:”MyUserId”}
(SINLogSeverityCritical log)
Failed to decode message transport
Failed to decode message transport
I wonder what situation causes this kind of problem.
Anyone with a similar problem?
Have you been using an older version of the Sinch SDK (iOS or Android) during testing? This problem might result from creating many instances for the same user id on multiple SDK versions. One way to test this hypothesis would be to start your Sinch client with a new unused user id using the latest SDK for iOS and Android (https://www.sinch.com/downloads/) - you should not be getting this error in that case. Meanwhile we will continue investigating on our side why those rare cases (as described above) are failing to connect.
Am using open fire server and iOS xmpp client with Robbie Hanson's framework. My clients runs fine in background, as i have set the voip flag and everything. But after few hours around 15-20, it automatically gets disconnected. Am not sure why it's happening and why it is taking such long duration. I am not sending any messages or receiving any. The ping interval is 360 secs to which my client responds with an error, which is acceptable form of response to remain connected to the server. Anyone got the same issue ?
Openfire server: 3.8.1
iOS version: 6.1.2
Did you try using the setting "Do Not disconnect clients that are idle" available in Server Settings> Client Connections in Openfire server?