Would reconnect_publisher be a thing?

[leisurehound]

This is more a question than an issue, but I'm exploring using this on a Pi to publish topics to a broker, however the Pi is headless and needs to just work(tm) when connected to a cellular router. I'm new to MQTT.

Is combining the aspects of reconnect_subscriber.c and simple_publisher.c viable? Am not sure if reconnect strategy is the same irregardless of being strictly a publisher. Also, can two sockets/struct clients be created to the same broker to publish multiple topics (at different update rates, effectively)? I see there are some mutex updates that infers this should be ok but curious if that is indeed the case.

BTW, I'm wrapping MQTT-C into a Swift wrapper so I can work in swift for the data logic bits.

TIA.

[leisurehound]

I'm getting a bad access error in Xcode debugger when attempting to publish for the first time at the if statement referencing curr->packet_id from __mqtt_next_pid called from mqtt_publish

/* check that the PID is unique */
        pid_exists = 0;
        for(curr = mqtt_mq_get(&(client->mq), 0); curr >= client->mq.queue_tail; --curr) {
            if (curr->packet_id == client->pid_lfsr) {
                pid_exists = 1;
                break;
            }
        }

[LiamBindle]

@leisurehound Thanks for writing.

Is combining the aspects of reconnect_subscriber.c and simple_publisher.c viable?

Absolutely. The examples are meant to be standalone demos of a certain feature/ability. The reconnect_subscriber demonstrates how the "reconnect" functionality is used (compare with simple_subscriber). For a real application you should implement your own handling and make use of the features you need (including potentially implementing your own PAL).

Also, can two sockets/struct clients be created to the same broker to publish multiple topics (at different update rates, effectively)?

Having mutliple mqtt_client is fine, and it's fine to connect them to the same broker. Note that you don't need multiple clients to publish at different rates. Doing mqtt_publish(...) stages the message for sending and it will be sent the next time mqtt_sync(...) is called. Assuming you're using a fixed sync rate (e.g., 500 ms) the rate of publishing is simply how often you do mqtt_publish().

BTW, I'm wrapping MQTT-C into a Swift wrapper so I can work in swift for the data logic bits.

Cool! Share the link when you're done, I'd be interested in checking it out.

I'm getting a bad access error in Xcode debugger when attempting to publish for the first time at the if statement referencing curr->packet_id from __mqtt_next_pid called from mqtt_publish

Sorry, I'm not familiar with the Xcode debugger. I'm afraid I don't have any insight.

[leisurehound]

I'm getting a bad access error in Xcode debugger when attempting to publish for the first time at the if statement referencing curr->packet_id from __mqtt_next_pid called from mqtt_publish

Sorry, I'm not familiar with the Xcode debugger. I'm afraid I don't have any insight.

ok, seems LLVM is not liking the mutex being set before the call __mqtt_next_pid where it references curr->packet_id