Hello Afzal, can you give an update on the availability of generic Coap? Thank you very much in advance!

@Stefan-de-Lange Allright, but isn’t LWM2M built on top of CoAP, which I can’t get to work in the first place? I also only need message confirmation (and QoS would be nice too) for now. There’s indeed a ton of material to be found on LWM2M (and CoAP), but that’s all high-level stuff that doesn’t seem to (directly) apply to the problem I’m having (my CoAP packets not arriving at T-Mobile or my endpoint).

Do you maybe know when I can expect more detailed documentation/tutorials/examples on how CoAP works with your network?

Also, the sign up form at https://iotcreators.com/en/installfest/ doesn’t seem to be working. I’d like to attend, is it already fully booked or can I still join?

@Stefan-de-Lange

The BK7020E does support CoAP, but I’m not getting any response from T-Mobile and the packet isn’t showing up in the portal or my endpoint. Is it possible that the BK7020E doesn’t use the CoAP I need? I’ve read something about needing Neulmessenger (https://github.com/otheruse/NeulMessenger)

This particular SIM/ESP32 combo worked fine with UDP so it’s not faulty hardware. I’m using the commands from https://simcom.ee/documents/SIM7020/SIM7020%20Series_CoAP_Application%20Note_V1.02.pdf. All commands seem to respond the way they should, and confirmed the IP/port are correct elsewhere in the forum. I’ve also registered the device for CoAP, and received messages back on my device using the {{base_url}}/m2m/endpoints/{{DeviceId}}/downlinkMsg/0/data API call before when using UDP. Any insight?

@Stefan-de-Lange said in IP for CoAP:

172.27.131.100

Thanks! That didn’t work yet, but at least now I know the problem lies somewhere else in my system.

Also btw, Google lists a lot of results from docs.iot.t-mobile.nl/* that seem to be stale. Following any link in that domain from google (for example https://docs.iot.t-mobile.nl/docs/developer-documentation) gives me the following warning that I can’t dismiss and bypass:

Same error copying the link address and pasting it in a new tab. In firefox I get a 403 forbidden error from cloudflare.

I can search using your built-in search in the documentation so it’s not really a problem, but it’s been like that for a while so I thought I’d let you know in case you weren’t aware.

I’m trying to get CoAP to work with my BK7020, and I can’t find the IP I need to connect with.

I’m following the application note at https://simcom.ee/documents/SIM7020/SIM7020%20Series_CoAP_Application%20Note_V1.02.pdf, and specifically need the IP for the AT+CCOAPNEW command at page 6. There’s a bunch of IPs and ports scattered around the documentation, but none of them seem to work here. I’m assuming the port I need is 15683

Any suggestions? Right now I’m not getting my +CCOAPNMI: so I assume my IP/ports aren’t configured correctly.

I’ve registered my device with “TMNL_COAP_AL” as the adaptationLayerName

@Stefan-de-Lange Thanks for the response! I assume our hardware is indeed at least partially at fault, as the BK7020E’s we are using often exhibits other strange behavior too. With some kind of message acknowledgement we could probably circumvent that. Looking for a different module is on our to-do list, but we have no time for that now.

Do you have any suggestions for tools/brokers/whatever we could use? CoAP or MQTT with QoS 1 seems like it would work, but I don’t see any path to actually using that yet. The “Getting started” section of the documentation is simple enough, but the “Getting Serious” part quickly goes right over my head. In the end, all I’m interested in is that my device gets some confirmation if T-mobile receives a packet, so I can resend or reset if transmissions fail. Right now we just send a packet to the CDP and hope it arrives.

The best thing I can come up with is using the {{base_url}}/m2m/endpoints/{{DeviceId}}/downlinkMsgBase64/0/data API call to send acknowledgements with message IDs back to our device so it can resend if it doesn’t receive an ACK. Which seems rather suboptimal as there are protocols like CoAP and MQTT that should handle these things, and the acknowledgements would only get sent to the device the next time it sends a message.

I still haven’t found any solutions, and now have some nice data to visualise the problem:
We send one packet with 2 data points every half hour. As you can see, we often have very big gaps in our data. And no way to distinguish between successful and failed sendings in our device. Logs from the periods where no data is received look completely normal.

As our application requires visualizing this data to clients, such a gap is pretty much unacceptable. Any advice on how we can ensure more packets get through? We have recently bought the biggest antenna we could find and will test that soon, but the reception at the location from the graph should be pretty good already, especially as NB-IOT should have very good reception.

@Eric-Barten mind chiming in?

@Stefan-de-Lange Thanks for the suggestion! We already have most of our development done with our own PCB using an ESP32 and SIM7020E. What I can gather about the nRF9160 is that we can either use a full DK or the SiP. Both seem prohibitive, as it would be wayyyy more work than just switching out the SIM breakout and changing AT commands and routines and such.

Am I correct in thinking this? I’d very much love to have (more) reliable data transfer, but also don’t have the time to do a large overhaul.

@Stefan-de-Lange Do you have suggestions for an alternative?

@Stefan-de-Lange Thanks for the suggestion! Both things I hadn’t considered yet. Will be looking into them.