Just setup first instance of Chirpstack v4.3.1 (long term user of Chirpstack) on a Ubuntu server. Added first device (having created device profile with Javascript codec etc. which is a temp/humidity sensor).
Link metrics is showing correct activity however both ‘Events’ and ‘LoRaWAN frames’ tabs are showing no data with the little spinning logo. The battery column for the device is correctly showing the icon for full battery.
When I subscribe to the MQTT feed it is showing the full payload from the device - including the codec output for the payload (with temperature, humidity data) so the back end functionality appears to be working correctly.
The gateway I am using is also showing as online - but no LoRaWAN frames are showing in the tab with the same logo spinning over the no data text.
Again when I subscribe to the mosquitto mqtt feed - everything appears to be working without issue.
Grateful for you taking the time to read my issue and any pointers (as to what I have done wrong) would be gratefully received - I hope the above makes sense. Thank you.
Uplink all appears fine. I can see from the mqtt feed that the payload is being processed without issue. The only thing that isn’t working is the display tab within Applications for both LoRaWAN frames and events and in the Gateways section for LoRaWAN frames.
Redis-server looks to be running fine with the log not showing any errors.
I’ll have to dig into it a little deeper - haven’t had experience of redis up until now.
Thank you for taking the time to respond - much appreciated.
Thank you @ric2498 for your kind response. The log from my limited perspective looks fine with no glaring issues presenting themselves. I have a few samples below.
(a). Log sample for when the LoRaWAN frames tab is selected in the Chirpstack portal:
2023-04-13T07:21:52.108851Z DEBUG chirpstack::framelog: Channel has been closed, returning
2023-04-13T07:22:03.290870Z DEBUG chirpstack::api::internal: Client disconnected
2023-04-13T07:22:03.307379Z DEBUG gRPC{uri=/api.ApplicationService/Get}: chirpstack::api: Started processing request
2023-04-13T07:22:03.309477Z INFO gRPC{uri=/api.ApplicationService/Get}: chirpstack::api: Finished processing request status="200" latency=2.1084ms
2023-04-13T07:22:03.329490Z DEBUG gRPC{uri=/api.DeviceService/Get}: chirpstack::api: Started processing request
2023-04-13T07:22:03.330943Z INFO gRPC{uri=/api.DeviceService/Get}: chirpstack::api: Finished processing request status="200" latency=1.4618ms
2023-04-13T07:22:03.349139Z DEBUG gRPC{uri=/api.DeviceProfileService/Get}: chirpstack::api: Started processing request
2023-04-13T07:22:03.351373Z INFO gRPC{uri=/api.DeviceProfileService/Get}: chirpstack::api: Finished processing request status="200" latency=2.2432ms
2023-04-13T07:22:03.358614Z DEBUG chirpstack::eventlog: Channel has been closed, returning
2023-04-13T07:22:03.370155Z DEBUG gRPC{uri=/api.InternalService/StreamDeviceFrames}: chirpstack::api: Started processing request
2023-04-13T07:22:03.371267Z INFO gRPC{uri=/api.InternalService/StreamDeviceFrames}: chirpstack::api: Finished processing request status="200" latency=1.1
(b). log sample on occasion when uplink is received from Gateway. XXXXANONXXXX is just anonymised data.
2023-04-13T07:30:11.389344Z INFO chirpstack::gateway::backend::mqtt: Message received from gateway region_config_id="eu868" topic="eu868/gateway/XXXXANONXXXX/event/stats" qos=0 json=false
2023-04-13T07:30:11.393613Z INFO stats{gateway_id=XXXXANONXXXX}: chirpstack::storage::gateway: Gateway state updated gateway_id=XXXXANONXXXX
2023-04-13T07:30:11.394175Z INFO stats{gateway_id=XXXXANONXXXX}: chirpstack::storage::metrics: Metrics saved name=gw:XXXXANONXXXX aggregation=HOUR
2023-04-13T07:30:11.394651Z INFO stats{gateway_id=XXXXANONXXXX}: chirpstack::storage::metrics: Metrics saved name=gw:XXXXANONXXXX aggregation=DAY
2023-04-13T07:30:11.395023Z INFO stats{gateway_id=XXXXANONXXXX}: chirpstack::storage::metrics: Metrics saved name=gw:XXXXANONXXXX aggregation=MONTH
2023-04-13T07:30:38.919781Z INFO chirpstack::gateway::backend::mqtt: Message received from gateway region_config_id="eu868" topic="eu868/gateway/XXXXANONXXXX/event/up" qos=0 json=false
2023-04-13T07:30:39.123654Z INFO up{deduplication_id=85ac7618-2245-46fd-9360-4e0996b816a9}: chirpstack::uplink: Uplink received m_type="UnconfirmedDataUp"
2023-04-13T07:30:39.123707Z DEBUG up{deduplication_id=85ac7618-2245-46fd-9360-4e0996b816a9}: chirpstack::uplink: Updating gateway meta-data for uplink frame-set
2023-04-13T07:30:39.126795Z DEBUG up{deduplication_id=85ac7618-2245-46fd-9360-4e0996b816a9}: chirpstack::uplink: Logging uplink frame to Redis Stream
2023-04-13T07:30:39.129146Z INFO up{deduplication_id=85ac7618-2245-46fd-9360-4e0996b816a9}:data_up: chirpstack::storage::device_session: Device-session saved dev_eui=XXXXANONXXXX dev_addr=XXXXANONXXXX
The only thing that stands out is a later entry which talks about a deduplication error.
2023-04-13T07:33:33.571061Z INFO chirpstack::gateway::backend::mqtt: Message received from gateway region_config_id="eu868" topic="eu868/gateway/XXXXANONXXXX/event/up" qos=0 json=false
2023-04-13T07:33:33.773616Z INFO up{deduplication_id=e7597724-e2a4-4f8f-bda5-a9ef29cdb94d}: chirpstack::uplink: Uplink received m_type="Proprietary"
2023-04-13T07:33:33.773655Z DEBUG up{deduplication_id=e7597724-e2a4-4f8f-bda5-a9ef29cdb94d}: chirpstack::uplink: Updating gateway meta-data for uplink frame-set
2023-04-13T07:33:33.775878Z DEBUG up{deduplication_id=e7597724-e2a4-4f8f-bda5-a9ef29cdb94d}: chirpstack::uplink: Logging uplink frame to Redis Stream
2023-04-13T07:33:33.776462Z ERROR chirpstack::uplink: Deduplication error error=Unexpected m_type: Proprietary
I hadn’t as everything is working fine - accepting payloads and processing them. I have integrations working without issue. Its just the tabs relating to viewing LoRaWAN frames (both in the Applications and Gateway sections) and the events tab in the Applications section of the Chirpstack portal which isn’t working.
I had such a problem. It fixed by returning the marshaller parameter to the ‘protobuf’ and specifying the same ‘topic names’ as indicated on the chirpstack website or in the chirpstack github repository. Look at configuration files once again.
@stephenb , have you tried to connect to your ChirpStack instance with another client (another PC)?
I’ve had the same issue last month and I was ready to ask help when I realized that my F-Secure Client Security tool was responsible of this behavior. It actually worked very well from everywhere except from my laptop.
In my case, I had to add the domain on the F-Secure exception list.
Sylvain
Thank you @montagny . I’ve been using a number of different clients to access the portal. All will be using Sophos AV which I will have to investigate further. Did you manage to fix whatever about f-secure was causing the issue?
@stephenb I’m having the same problem, I’ve noticed that if I restart the redis server the last 10 events shows up and then doesn’t show the new events. Connecting from a virtual linux machine the events show up correctly. I’ve also sophos on my pc. I’m also investigating.
First off - welcome to the community @SimoneA
Restarting the Redis server isn’t making any difference in my case even on a temporary basis. Its an annoyance but thankfully everything else is working. Having the frames is really helpful when trying to understand why something isn’t working correctly and for seeing an overview of activity/frequency of activity. I’ll keep on trying to get to the bottom of it.
Thanks @stephenb.
My problem is that sophos is blocking, disabling sophos resolved my issue. I don’t know why, my IT guys are checking it, when I have news I’ll update you.
The live data and frame-logs rely on gRPC-web streams. In the past I have seen that these streams are sometimes blocked at the client-side (e.g. virus scanners). In case a proxy is used, this requires additional configuration to make sure the proxy does not wait with forwarding until a timeout occurs (it should return the stream from the backend immediately to the client). For example in case of NGINX you need to use grpc_pass:
Thank you @brocaar and everyone for their responses. It is looking like the Anti-Virus client is causing the issue. Due to the specific deployment environment a work around isn’t going to be simple but at least I know the cause. Thanks again everyone.