Here it is running headless on my Window's desktop.

The ESP8266 "Sensor Node" sending at 1 second intervals (while development) is working out very nicely.  I haven't finished the re-sends communications yet for missed / corrupted messages.  But all the deep sleep, node registering with the server handshaking and primary data sending goals are done.  Currently with polling three sensors (2) Temperature, Humidity, Pressure and supply voltage, sending the packet and waiting for a confirmation takes 45 milli-seconds.  I'm assuming (worse case) it'll get worse with range, but that is yet to be determined.  It should have fantastic battery life.  

I've spent extra effort making the node-side library as lean as possible as I expect to make many of these nodes for different things.  I'm glad I got a 5 pac of LoRa modules.  I already have plans for them:

• One bee-hive
• One for a weather station
• One for the mailbox at about 300 yards away for notification.
• One in the attic to monitor temperature / humidity
• One in the crawl-space to monitor temperature / humidity

Here is total Sketch code.  99% is comments and sensor related... only about 3-lines of code are added to do a LoRa / Deep Sleep solution. 😉 

#include <InqNode.h>
#include <Adafruit_AHTX0.h>
#include <Adafruit_BMP085.h>

// These constants must be filled out ==========================================
// CHANNEL - A InqVault server will listen on one channel.  All nodes talking
//      to that server must use the same channel.
const u32 CHANNEL = 42;             
// FREQUENCY - Must be the same LoRa frequency as your InqVault server and
//      also comply with frequency in your region.  North America = 915000000.
const u32 FREQUENCY = 915000000; 
// META - These are descriptors of the package fields.  Nominally these are
//      sensor data being stored on the InqVault.  They get registered with 
//      the server and are exposed out to your Web Browsers GUIs.  Consists of:
//      <node name>:
const char* META = "InqBee:TemperatureOutside(°C),TemperatureInside(°C),\
HumidityInside(%M),Pressure(mbar),Voltage(V),HumidityOutside(%),Weight(kg),\
Light(lm)";                         
// PACKAGE - A C struct with "float" fields of very value you wish to retain
//      on the InqVault server database.
struct InqBee
{
    float temperatureOutside;   // (°C)
    float temperatureInside;    // (°C)
    float humidityInside;       // (%M)
    float pressure;             // (mbar)
    float voltage;              // (mV)
    float humidityOutside;      // (%)
    float weight;               // (kg)
    float light;                // (lm)
};

// Sensor Declarations =========================================================
ADC_MODE(ADC_VCC);
Adafruit_BMP085 bmp180;     // Uses standard I2C bus - SCL=D1, SDA=D2
Adafruit_AHTX0 aht10;       // Uses standard I2C bus - SCL=D1, SDA=D2

void setup()
{
#ifdef DEBUG
    Serial.begin(115200);
    delay(1000);
    dbg("\n");
#endif
    // Create the package for sending data -------------------------------------
    InqBee* pkg = CreatePackage(InqBee, META, CHANNEL, FREQUENCY);

    // Update the package with sensor data as necessary ------------------------
    pkg->voltage = ESP.getVcc() * 0.01;

    if (aht10.begin())
    {
        sensors_event_t humid, temp;
        aht10.getEvent(&humid, &temp);
        pkg->temperatureInside = temp.temperature;             // °C
        pkg->humidityInside = humid.relative_humidity;         // %M
    }

    if (bmp180.begin())
    {
        pkg->temperatureOutside = bmp180.readTemperature();    // °C
        pkg->pressure = (float) bmp180.readPressure() * 0.01;  // mbar
    }
    
    // Send the package --------------------------------------------------------
    PostPackage();
}

void loop() 
{ 
}

Library - Unfortunately I ended up having to cobble several together.  I've gotten used to the Sandeep Mistry one @dronebot-workshop recommended for our Arduino/ESP's.  Meaning... it seemed to be a pretty clean port.  I found a Github that ported it to RasPi - https://github.com/loraraspi91/LoRa4Raspi.  However, it uses a pin library (wiringPi.h) that has been totally abandoned.  Using this page https://elinux.org/RPi_GPIO_Code_Samples#Direct_register_access, I tried to select one that is still being regularly used, seems to still be supported and has few "Issues".  They're all 3rd party and not supported by the RasPi organization.  Which is very unfortunate.  I finally decided to go with 1.5 pigpio as it has very thorough documentation https://abyz.me.uk/rpi/pigpio/cif.html#spiOpen on how to install and use it.  It also supports interrupt callbacks from its SPI functions.  Many of the other pin libraries did not.  The Sandeep Mistry library did not have code to use interrupts.  You have to poll for a message.  Very fugly!  I found a second LoRa library that uses this pigpio, https://github.com/YandievRuslan/sx1278-LoRa-RaspberryPi.  It would not work for me, after I tried to make the adjustments for North America.  I was able to read the code well enough to use some of its pigpio usage techniques in modifying the Sandeep Mistry version. 

Also note, it appears that the RasPi 5 is using a new/different pin I/O chip than all the previous RasPi's.  What this means - all these pin libraries above and the libraries (like LoRa libraries) that use them will not work on a RasPi 5!  I did not comprehensively research this because I am targeting the low-end of RasPi's.  I'm doing development on a RasPi 4, but will be running these on RaspPi Zero-W's.  I also have a Orange-Pi Zero W showing up.  I look forward to seeing what these clone boards are like.  

Half-Duplex - Nah... its not a problem I can throw software at and fix.  The libraries I've been working with have to put it in TX mode or RX mode... so having a separate thread monitoring it, is not possible.  It's like radios... you have to key the mike and while keyed, you can't receive anything.  I have nodes and servers sending and then immediately going into RX mode.  I have not experimented with contention yet, but even in perfect (6" range) conditions, packets are missed.  So its not a stretch to assume they'll be missed when in TX mode.

VBR,

Inq

Have been working on moving to a Raspberry Pi for a server for the potentially "many" sensor stations.  I've never really worked with a RasPi for development.  I'm actually finding it pleasing.  I'm using a headless RasPi 4B for development and it actually is far faster compiling than Arduino IDE or Visual Studio on an i7 Windows box. 

I chose not to do the full "Recommended Extras" setup, but building C++ projects worked out of the box with JUST the "Desktop" install.  Getting it to work with the LoRa modules was another story.  Because of recent changes for the RasPi 5, there are many breaking changes in Pin I/O libraries and SPI libraries and thus LoRa libraries.  Most libraries are broke, deprecated or the Open-Source developer, abandoned the project.  I did finally find a combination that works and now have a bare bones LoRa server working on the RaspPi.  

LoRa Performance

In that regard I have it working non-stop on a ESP8266, sleeping client to the RasPi  server.  I wanted to give a statistic for anyone contemplating a LoRa project.  

• Delivery is not assured.  If your data HAS to get there every time, you'll need to roll your own TCP like protocol.  (Although the LoRaWan may do that)
• It is basically half-duplex.  You can't receive and send at the same time.  So while the server is sending back a response, it might miss messages from other nodes.
• I have one Node sending a message once / second.  Nothing too demanding.  They are about a meter apart.  
  • Missed messages are about 0.1% of the time.  Good - but not reliable.
  • Corrupted messages (Invalid CRC) are about 0.05% of the time.
  • I'd assume it to get worse with distance... like 300 meters! - I'll update when I get a test rig in that condition.

VBR,

Inq

Sorry, I guess I should have explained, my training is pre internet, the only training I ever got in that area was tcp/ip and udp. Knowing all the nitty gritty details of the various headers etc isn't much help to me now plus I have forgot it all in any case. Java to me is coffee.

I did look at some of your samples, but it may as well be written in greek.

Just to put this old dinosaur in perspective, I used to submit searches on 3 part memos in the late 70's, the results would come back a few days later printed on 15 1/2" x 11 1/2" paper and occasionally if I entered a search with too broad a criteria a small hand truck would show up with a few hundred pounds of what was now waste paper, and we did't even re-cycle in those days!

@inq Those links are OOS

Well... yeah!  What'd you expect?  You asked for my links.  I don't buy my stuff from Canada to make it easier for you to find.

Ah well, google is my friend.

The graphing is purely web development stuff.  Has nothing to do with Arduino, ESP8266 or InqPortal.  It's a JavaScript library.  There are plenty of free JavaScript libraries to do any kind of graphics, dashboards, dials, gauges etc.  If/when I get the RaspberryPi server working, it'll use the same library for graphing out to a webpage.

You are right, I did miss that lora and wifi aspect.

Since I can't follow the Inq stuff, I will just forget about using Inq and an 8266. Too bad, it looks very cool. Ah well, google is my friend.

I assume creating that graph is documented in your Inq stuff?

They're both extremely common.  Doing a search on your favorite vendor will likely find you tons of hits even cheaper.  Even on Amazon, I consider this to be dirt cheap.

BMP280 (Temperature/Pressure) - https://amz.run/7MlW

AHT10 (Temperature/Humidity) - https://amz.run/7MlX - I used to use the DHT11 and DHT22 in my classes and gave them out like candy.  I bet I got 50% failures with them.  I don't know if students were miss-wiring them, but I even had them go bad in working systems after a while.  I've not had one AHT10 go bad.  They're more accurate and cheaper to boot.

As you can see both sensors are on the same I2C bus and work just fine.

InqStuff 🤣 - (Remember its only on ESP8266) Yes, it is documented in several places on the website.  Even the 5 minute read of the "Quickest Start Guide" here in my signature walks through the whole process all the way to graphing one of your custom published variables (sensor data) and even to the using the wizard to pump out a custom Dashboard webpage.  

But... the InqStuff doesn't support LoRa unless you make a base station with an ESP8266 that has both LoRa and WiFi running like I did in the example above.

VBR,

Inq

I left it running over night in my office.  Note how sensitive the gauges are over the last hour since I merely walked into the office and started breathing humidity into the room and me and the computer added a little more heat.  No other adjustment to the room was made.

Very impressive. At some point I will want to do that for my garden, and since other people may want the same thing, do you have a source other than ebay for great prices in quantities of 10 for the two sensors?

I assume creating that graph is documented in your Inq stuff?