Forum Replies Created
-
AuthorPosts
-
@zeke-holloman do you want to send me the thingspeak details on my email neilh20@wLLw.net and I’ll try them in my setting. I have a historical thingspeak account which has exceeded its free quota, so I can’t create more devices.
The hologram account should work with the Xbee LTE ( I have an XB3-CA2-UT-001) if setup, and I started with hologram. If it works for getting time, should work for any other connection. If you post the trace can see if its getting good response .
@vogelrnws gosh sounds interesting, especially as you are logging the readings. I couldn’t see the python files – could you provide a link.
https://thingspeak.com/channels/5940 shows a data point at Aug 02 2021 15:17 GMT-0700 Yeah!!
@zeke-holloman, I figured out that the other day I hadn’t changed the apn to the source I was using.
So with your code, my apn and thingspeak API, using tera-term 4.105 with TimeStamp and the following changes I got a good response from thingspeak
#include <ModularSensors.h> //pre 0.30.0 was <LoggerBase.h></div>
The core thingspeak looks like this
1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889nh: it got time OK[2021-08-02 15:16:04.029] Setting up file on SD cardnh: zzz sleeping[2021-08-02 15:16:04.173] Data will be saved as logger_2021-08-02.csv[2021-08-02 15:16:04.198] Putting processor to sleep[2021-08-02 15:17:00.586] ------------------------------------------[2021-08-02 15:17:14.269][2021-08-02 15:17:14.269] \/---- Line Saved to SD Card ----\/[2021-08-02 15:17:14.269] 2021-08-02 17:17:00,-9999.0,-9999.00,-9999.0,4.548,-81[2021-08-02 15:17:14.288][2021-08-02 15:17:14.288][2021-08-02 15:17:14.444] +++OK[2021-08-02 15:17:14.557] ATCN[2021-08-02 15:17:14.557] OK[2021-08-02 15:17:14.932] +++OK[2021-08-02 15:17:15.052] ATAP[2021-08-02 15:17:15.073] 0[2021-08-02 15:17:15.073] ATGT[2021-08-02 15:17:15.073] 64[2021-08-02 15:17:15.073] ATCT[2021-08-02 15:17:15.076] 64[2021-08-02 15:17:15.076] ATHS[2021-08-02 15:17:15.076] B08[2021-08-02 15:17:15.076] ATCN[2021-08-02 15:17:15.092] OK[2021-08-02 15:17:15.224] +++OK[2021-08-02 15:17:15.324] ATAI[2021-08-02 15:17:15.355] 0[2021-08-02 15:17:15.355] ATMY[2021-08-02 15:17:15.355] 100.111.10.79[2021-08-02 15:17:15.371] ATCN[2021-08-02 15:17:15.430] OK[2021-08-02 15:17:15.430] Sending data to [ 0 ] mqtt.thingspeak.com[2021-08-02 15:17:15.430] 5 fields will be sent to ThingSpeak <--ThingSpeakPublisher[2021-08-02 15:17:15.430] Topic [ 38 ]: channels/5940/publish/DHCKWXXHZQLHGIAX <--ThingSpeakPublisher[2021-08-02 15:17:15.430] Dumping the TX Buffer <--dataPublisherBase[2021-08-02 15:17:15.430] Message [ 106 ]: created_at=2021-08-02T17:17:00-05:00&field1=-9999.0&field2=-9999.00&field3=-9999.0&field4=4.548&field5=-81 <--ThingSpeakPublisher[2021-08-02 15:17:15.430] Opening MQTT Connection <--ThingSpeakPublisher[2021-08-02 15:17:15.524] +++OK[2021-08-02 15:17:15.640] ATLAmqtt.thingspeak.com[2021-08-02 15:17:17.797] 3.83.181.186[2021-08-02 15:17:17.812] ATIP[2021-08-02 15:17:17.812] 1[2021-08-02 15:17:17.812] ATDL[2021-08-02 15:17:17.828] 132.163.97.6[2021-08-02 15:17:17.844] ATDL3.83.181.186[2021-08-02 15:17:17.859] OK[2021-08-02 15:17:17.859] ATDE[2021-08-02 15:17:17.881] 25[2021-08-02 15:17:17.881] ATDE75b[2021-08-02 15:17:17.897] OK[2021-08-02 15:17:17.897] ATWR[2021-08-02 15:17:17.952] OK[2021-08-02 15:17:17.952] ATAC[2021-08-02 15:17:17.972] OK[2021-08-02 15:17:17.972] ATCI[2021-08-02 15:17:17.981] FF[2021-08-02 15:17:17.981] ATCN[2021-08-02 15:17:17.999] OK[2021-08-02 15:17:17.999] $MQTTÂMSMSZXG6QS4IXEHKG0PK+++OK[2021-08-02 15:17:18.260] ATCI[2021-08-02 15:17:18.282] FF[2021-08-02 15:17:18.282] ATOD[2021-08-02 15:17:18.282] 0.0.0.0[2021-08-02 15:17:18.298] ATCN[2021-08-02 15:17:18.298] OK[2021-08-02 15:17:19.898] MQTT connected after 4483 ms <--ThingSpeakPublisher[2021-08-02 15:17:19.921] 0&channels/5940/publish/DHCKWX0HZQLHGIAXcreated_at=2021-08-02T17:17:00-05:00&field1=-9999.0&field2=-9999.00&field3=-9999.0&field4=4.548&field5=-81+++OK[2021-08-02 15:17:20.304] ATCI[2021-08-02 15:17:20.304] 0[2021-08-02 15:17:20.304] ATOD[2021-08-02 15:17:20.324] 3.83.181.186[2021-08-02 15:17:20.324] ATCN[2021-08-02 15:17:20.338] OK[2021-08-02 15:17:20.338] ThingSpeak topic published! Current state: 0: MQTT_CONNECTED[2021-08-02 15:17:20.357] Disconnecting from MQTT <--ThingSpeakPublisher[2021-08-02 15:17:20.357] à+++OK[2021-08-02 15:17:20.581] ATTM[2021-08-02 15:17:20.597] 64[2021-08-02 15:17:20.597] ATTM64[2021-08-02 15:17:20.613] OK[2021-08-02 15:17:20.613] ATWR[2021-08-02 15:17:20.661] OK[2021-08-02 15:17:20.661] ATAC[2021-08-02 15:17:20.677] OK[2021-08-02 15:17:20.677] ATCN[2021-08-02 15:17:20.691] OK[2021-08-02 15:17:20.691] Disconnected after 347 ms <--ThingSpeakPublisher[2021-08-02 15:17:20.818] +++OKI have a lot more debug, and better scale-ability built into my fork https://github.com/neilh10/ModularSensors but the above worked for me.
Hello @rick-vogel – sounds fascinating & fun to use python in the Xbee. Though for ModularSensors there are layers of software that allow the physical modem to be abstracted so it could be possible to use another LTE when it becomes available (0.30.0 seems to have hooks for a new LTE modem SIM7080G) – through TinyGSM. As a Class package that @srgdamiano has put together its quite comprehensive – though as with all abstractions it has upsides and downsides. I think this is working through what it takes to figure out the control flow, which would be needed whatever route is taken. In my fork (with some LTE interface changes) it has worked.
@zeke-holloman, I’d got pulled off onto something else, now I’ve added the STREAMDEBUGGER_DBG to your “Logging_to_Thingskeak5.ino”and removed my extra code that I had and about to test it – but I have to get another dataplan going to test it – I use https://dataplans.digikey.com/ that has a 50Mbytes/month plans,1234567891011121314151617181920212223242526272829303132333435363738394041424344454647/ ==========================================================================// Wifi/Cellular Modem Options// ==========================================================================/** Start [xbee_cell_transparent] */// For any Digi Cellular XBee's// NOTE: The u-blox based Digi XBee's (3G global and LTE-M global) can be used// in either bypass or transparent mode, each with pros and cons// The Telit based Digi XBees (LTE Cat1) can only use this mode.HardwareSerial& modemSerial = Serial1; // Use hardware serial if possible#if defined STREAMDEBUGGER_DBG#include <StreamDebugger.h>StreamDebugger modemDebugger(modemSerial, STANDARD_SERIAL_OUTPUT);#define modemSerHw modemDebugger#else#define modemSerHw modemSerial#endif // STREAMDEBUGGER_DBG#include <modems/DigiXBeeCellularTransparent.h>const int32_t modemBaud = 9600; // All XBee's use 9600 by default// Modem Pins - Describe the physical pin connection of your modem to your board// NOTE: Use -1 for pins that do not apply// The pin numbers here are for a Digi XBee with a Mayfly and LTE adapter// For options https://github.com/EnviroDIY/LTEbee-Adapter/edit/master/README.mdconst int8_t modemVccPin = -1; // MCU pin controlling modem power// Option: modemVccPin = A5, if Mayfly SJ7 is// connected to the ASSOC pinconst int8_t modemStatusPin = 13; // MCU pin used to read modem status// NOTE: If possible, use the <code>STATUS/SLEEP_not</code> (XBee pin 13) for status, but// the CTS pin can also be used if necessaryconst bool useCTSforStatus = false; // Flag to use the CTS pin for statusconst int8_t modemResetPin = 20; // MCU pin connected to modem reset pinconst int8_t modemSleepRqPin = 23; // MCU pin for modem sleep/wake requestconst int8_t modemLEDPin = redLED; // MCU pin connected an LED to show modem// status// Network connection informationconst char* apn = "hologram"; // APN for GPRS connection// Create the modem objectDigiXBeeCellularTransparent modemXBCT(&modemSerHw, modemVccPin, modemStatusPin,useCTSforStatus, modemResetPin,modemSleepRqPin, apn);// Create an extra reference to the modem by a generic nameDigiXBeeCellularTransparent modem = modemXBCT;/** End [xbee_cell_transparent] */hello @zeke-holloman. Just looking through it, and yes thats my assumption at the moment is that its the cellular side that is not connecting.
There are 2 parts 1) getting internet & time 2) thingspeak.
1) If the cell phone connects for NIST time, then it can connect with the internet, and the cell modem account setting is good.2) if thingspeak then doesn’t connect its something to do with the account ino.
I’m just looking at your posted new file
The STREAMDEBUGGER_DBG is a bit strange, it should really be this
12345678910111213141516171819202122232425// ==========================================================================// Wifi/Cellular Modem Options// ==========================================================================// NOTE: Extra hardware and software serial ports are created in the "Settings// for Additional Serial Ports" sectionHardwareSerial& modemSerial = Serial1; // Use hardware serial if possible#if defined STREAMDEBUGGER_DBG#include <StreamDebugger.h>StreamDebugger modemDebugger(modemSerial, STANDARD_SERIAL_OUTPUT);#define modemSerHw modemDebugger#else#define modemSerHw modemSerial#endif // STREAMDEBUGGER_DBG//#define DigiXBeeCellularTransparent_Module#define DigiXBeeWifi_Module#ifdef DigiXBeeCellularTransparent_Module/** Start [xbee_cell_transparent] */// For any Digi Cellular XBee's// NOTE: The u-blox based Digi XBee's (3G global and LTE-M global) can be used// in either bypass or transparent mode, each with pros and cons// The Telit based Digi XBees (LTE Cat1) can only use this mode.#include <modems/DigiXBeeCellularTransparent.h>const int32_t modemBaud = 9600; // All XBee's use 9600 by defaultThe log you posted with some basic cell phone interface is looking very minimal. Possibly also compile it with
-DMS_DATAPUBLISHERBASE_DEBUG
-DMS_THINGSPEAKPUBLISHER_DEBUG-DSTREAMDEBUGGER_DBG
.
I was thinking of creating a branch off envirodiy (master) – and seeing if it can be referenced for an update to the cell phone interface so it can show more detail. Gotta try it out.@zeke-holloman – I have no idea why my previous post came out so badly, and it won’t allow me to edit it!!. My usual way of recovering strange posts.
It should be interesting to see what you get with your cell modem.
Using your sketch, which references the latest ModularSensors
Using ModularSensors Library version 0.30.0
TinyGSM Library version 0.11.4My cell modem which is running on Verizon wouldn’t connect. The modem issues are technical and I believe understood, and have been discussed.
This specific modem has been working no problem in my fork which has modifications for managing the startup of the cell modem and works for the cell company I’ve been using …. my fork currently is at ModularSensors 0.28.5
I did try compiling your program in my fork, but there is some changes in 0.30.0 that aren’t backward compatible, so I need to upgrade before I can try this.
Still with your software, referncing MS 0.30.0 I switched the modem to Digi WiFi S6B, which I use a lot in testing, and it worked no problem.
Once connected to an TCP/IP link – whether over cell or wifi – the passage of data is the same, though Modem AT cmds may be a little different.
So this is what I get
123456789101112131415161718192021222324252627282930Sending data to [ 0 ] mqtt.thingspeak.com5 fields will be sent to ThingSpeak <--ThingSpeakPublisherTopic [ 38 ]: channels/5940/publish/DHCKWX0HZQLHGIAX <--ThingSpeakPublisherDumping the TX Buffer <--dataPublisherBaseMessage [ 106 ]: created_at=2021-07-29T18:34:00-05:00&field1=-9999.0&field2=-9999.00&field3=-9999.0&field4=4.761&field5=-25 <--ThingSpeakPublisherOpening MQTT Connection <--ThingSpeakPublisher+++OKATLAmqtt.thingspeak.com34.194.225.123ATIP1ATDL132.163.97.6ATDL34.194.225.123OKATDE25ATDE75bOKATWROKATACOKATCNOK$MQTTÂMSMSZ0G6QS4IXEHKG0PK MQTT connected after 838 ms <--ThingSpeakPublisher0&channels/5940/publish/DHCKWX0HZQLHGIAXcreated_at=2021-07-29T18:34:00-05:00&field1=-9999.0&field2=-9999.00&field3=-9999.0&field4=4.761&field5=-25ThingSpeak topic published! Current state: 0: MQTT_CONNECTEDDisconnecting from MQTT <--ThingSpeakPublisherà+++OKATTM@zeke-holloman interesting, seems like it should work.
When I have strange issues, I delete the .pio/… and force it to do a refresh with all the remote libs. I see you are using the DecagonCTD which recently changed to hydros21, but seems like it should work.
I’ve taken your platformio.ini and program and adding my thingspeak keys, and will try running. I have a test system with Digi LTE I’m in the process of switching so I can try your setup
In the meantime
platformio.ini to
build_flags = -DSTREAMDEBUGGER_DBG #usually add at end of list
lib_deps =
https://github.com/vshymanskyy/StreamDebugger ;Debug when neededlogging_to_thinkgspeak : look for DigiXBeeCellularTransparent and make changes
// Create the modem object
<span style=”color: #ff0000;”>#if defined STREAMDEBUGGER_DBG</span>
<span style=”color: #ff0000;”>#include <StreamDebugger.h></span>
<span style=”color: #ff0000;”>StreamDebugger modemDebugger(modemSerial, STANDARD_SERIAL_OUTPUT);</span>
<span style=”color: #ff0000;”>#define modemSerHw modemDebugger</span>
<span style=”color: #ff0000;”>#else</span>
<span style=”color: #ff0000;”>#define modemSerHw modemSerial</span>
<span style=”color: #ff0000;”>#endif // STREAMDEBUGGER_DBG</span>
DigiXBeeCellularTransparent modemXBCT(&<span style=”color: #ff0000;”>modemSerHw</span>, modemVccPin, modemStatusPin,
useCTSforStatus, modemResetPin,
modemSleepRqPin, apn);@zeke-holloman a correction on my part, when I looked through the thingspeak API, both the historical and the MQTT method use the POST to deliver it to thingspeak, however they have a slightly different API.
Initially when looking at your posting I assumed you had removed the keys as it was public, however looking at your your trace it is saying that it doesn’t have the keys in it.
Your response is
Topic [ 41 ]: channels/thingSpeakChannelID/publish/thingSpeakChannelKeyand it should look something like
Topic [ 38 ]: channels/5940/publish/DHCKWX0HZQLXGIAX <–ThingSpeakPublisher
Please confirm that your run has the API keys in.
If that doesn’t work, can you post your platformio.ini
I’m committed to something for the next couple of hours but I can add describe the STREAMDEBUG setup after looking at your platformio.ini
Hi @zeke-holloman – looks like the ThingSpeak keys and channel need to be added.
Add them to (the following are examples)
const char* thingSpeakMQTTKey =
“Z0G6QX4IXEHKG0PK”; // Your MQTT API Key from Account > MyProfile.
const char* thingSpeakChannelID =
“5940”; // The numeric channel id for your channel eg
const char* thingSpeakChannelKey =
“DHCKWX0HZQLXGIAX”; // The Write API Key for your channelYour response is
Topic [ 41 ]: channels/thingSpeakChannelID/publish/thingSpeakChannelKeyand it should look something like
Topic [ 38 ]: channels/5940/publish/DHCKWX0HZQLXGIAX <–ThingSpeakPublisher
Followed by this
Dumping the TX Buffer <–dataPublisherBase
Message [ 129 ]: created_at=2021-07-28T19:04:00-08:00&field1=1&field2=2000.000&field3=-0.223&field4=4.1748&field5=4.215&field6=22.20&field7=0.0088 <–ThingSpeakPublisher
Opening MQTT Connection <–ThingSpeakPublisher
MQTT connected after 874 ms <–ThingSpeakPublisher
ThingSpeak topic published! Current state: 0: MQTT_CONNECTED
Disconnecting from MQTT <–ThingSpeakPublisher
Disconnected after 418 ms <–ThingSpeakPublisherI’ll have to get about streamdebugger as heading out the office, back in 2hrs
For debug you should see the following in platformIO.ini – add it to the end. It will force a complete recompile
<!–more–>
[env:mayfly]
monitor_speed = 115200
board = mayfly
platform = atmelavr
framework = arduino
lib_ldf_mode = deep+
lib_ignore =
RTCZerobuild_flags =
-DSDI12_EXTERNAL_PCINT
-DNEOSWSERIAL_EXTERNAL_PCINT
-DMQTT_MAX_PACKET_SIZE=240
-DTINY_GSM_RX_BUFFER=64
-DTINY_GSM_YIELD_MS=2
-DMS_DATAPUBLISHERBASE_DEBUG
-DMS_THINGSPEAKPUBLISHER_DEBUG -
AuthorPosts