Switched the device to MQTT mode using the windows VIRCOM configuration tool and setup the menu for my local broker server configuration.


I get the BLUE connect led on the module so that seems to be working.

Next step is to send data. I used a RS-232 protocol converter board I built for another project to generate test data.


That plugs into the MQTT device RS-232 plug.


Fragment of the PIC18F14Q41 test program.

void main(void)
{
    uint8_t count=0;
    // Initialize the device
    SYSTEM_Initialize();

    TMR0_SetInterruptHandler(tmr0isr);
    TMR1_SetInterruptHandler(delayisr);

    // Enable high priority global interrupts
    INTERRUPT_GlobalInterruptHighEnable();

    // Enable low priority global interrupts.
    INTERRUPT_GlobalInterruptLowEnable();

    TMR0_StartTimer();
    TMR1_StartTimer();

    while (1) {
        // Add your application code
        MLED_Toggle();
        wdtdelay(100000);
        if (UART1_is_tx_ready()) {
            /*
             * STDIO redirected to UART1
             */
            printf("MQTT POE Testing %d \r\n",count++);
        }
    }
}

Wonderful! I see the published data string from a remote subscriber also connected to the broker.

 

The pure TTL to Ethernet module is faster than the serial MQTT gateway interface but requires local processing (2000 lines for this embedded version 3.1.1) to handle the MQTT protocol on a 32-bit controller. The POE MQTT gateway device seems to work as advertised and is easily driven by a 8-bit controller to publish data in simple JSON format.


Reading both controllers publishing streams on the remote subscriber computer.

 

I bought a USR N510, and got it working on the Tago.io platform.
The N510 has a MQTT mode, which isn’t particularly difficult to get working, and only a little bit annoying.
I also bought the Waveshare module, and I’ll try that next,
By the way, is USR the same US Robotics that made dial up modems? (I still have one, and I’m sure it will do me a lot of good now that my telephones are VOIP!)

 

By the way, is USR the same US Robotics that made dial up modems? (I still have one, and I’m sure it will do me a lot of good now that my telephones are VOIP!)

The company is entirely unrelated to US Robotics being a newly founded Chinese company apparently actually called “PUSR”.

The also call themselves USRIoT in some cases.

 

Where did you get VirCom? The only version I found downloads a .rar file, which I gave to my Linux machine to extract and it crashed

 

I've used the PUSR USR-TCP232-T2/S2. It a clone of the Waveshare TTL to Ethernet device.
https://www.pusr.com/products/serial-to-ethernet-converter-modules-usr-tcp232-t2.html

Where did you get VirCom? The only version I found downloads a .rar file, which I gave to my Linux machine to extract and it crashed

They don't have Linux version. It runs on Windows 10/11.

 

Another MQTT demo project using WFI for 3-axis inclinometer and 3-axis acceleration: This module puts the S for security in IoT.

It's a heavy modified version of the original code example for reading (2MHz SPI) the IMU on a click board: https://github.com/nsaspook/iot_wfi32e_scl3300/tree/main/apps/paho_mqtt_client
No RTOS, bare-metal C code.

https://www.microchip.com/en-us/product/wfi32e01pc
SCL3300: https://www.murata.com/-/media/webr...datasheet/datasheet_scl3300-d01.ashx?la=en-sg


Displaying IMU data subscribed from the MQTT broker sent by the wireless board. Data packet update rate, 5Hz.

 

Back on this project.
One thing I have discovered is that none of the platforms is particularly engineer-friendly. Every company seems to be trying to sell to engineers (i.e. someone who has some physical parameters that need measuring and logging) but I doubt that any of them have ever spoken to an engineer before, because everything is in computer-speak; and they all have silly made-up names for the same thing: Datastreams, Buckets, Silos, all appear to have the same meaning.
Blynk seems to be the easiest (yes, it was the first one mentioned on this thread, thank you, @Ya’akov )
The efficiency of the interface is also very variable.
for instance, to update parameters on Blynk using MQTT
{Voltage: 47.6,
Current: -2.2}

but elsewhere:

{Parameter: Voltage}
{Format: Float}
{Data: 47.6}
{Parameter: Current}
{Format: Float}
{Data: -2.2}