Meinst Du mit Queue "$hash->{messages}"? Ja, {qos} wird ja an die "send_xxx" subs mitgegeben und in Message.pm mit in die Nachricht (hash) mitgenommen. Nachricht-Hash landet dann in "$hash->{messages}->{msgiid}".
Das deckt sich nicht mit meinem Verständnis: Wenn, dann müßte es irgendein Unterhash von dem sein, was sich aus
my $message = Net::MQTT::Message->new(%msg);
ergibt. Vermutlich könnte man da auch auf die "inneren Werte" zugreifen, aber das hatte ich bei meinem Vorschlag übersehen...
Was sub send_publish() angeht - müßte das nicht so starten:
sub send_publish($@) {
my ($hash,%msg) = @_;
if (!$msg{qos}) {
Eigentlich dachte ich, das Modul ist reif zum Einmotten, jedoch sehe ich, dass es noch Nutzer gibt, denen es wichtig ist.
Na ja, vielleicht sollte man es wirklich mittelfristig einmotten, aber wir bräuchten dann einen Plan, wie das gehen soll, damit niemand aus allen Wolken fällt. Da die meisten User vermutlich die kommenden Monate vor dem Problem stehen werden, dass sie updaten müssen, wäre vermutlich jetzt ein guter Zeitpunkt, um zumindest diese Kommunikation in die Richtung zu machen...
Stichworte:
- MQTT_BRIDGE direkt nach contrib, (v.a. auch UPDATE nicht vergessen)
- commandrefs von
-- MQTT_DEVICE Vorbemerkung in Richtung "use MQTT2_DEVICE instead" (für neue User!)
-- MQTT: (analog)
-- MQTT_GENERIC_BRIDGE (low prio): Beispiel (falls vorhanden weg von MQTT nach MQTT_CLIENT)
- Einen Satz Module (samt den 2016-er libs, falls getestet ist, dass die "ok" sind) mal aktuell ausliefern, damit "updater" ohne cpan auskommen, in ca. 6 Monaten die libs löschen, Installation dann nur noch via cpan?
- in ca. 12-18 Monaten dann "BRIDGE" nach "deprecated", MQTT+MQTT_DEVICE nach contrib (oder in dem Zug der Entfernung der libs alles "mittelfristige" direkt nach contrib?
@Rudi:
Gibt es eigentlich einen Plan für 6.1? (Spätestens,) wenn "MQTT-classic" raus ist, wäre es eventuell Zeit für einen Versionswechsel (kann auch 6.2 sein)? (Aber bitte nicht grade jetzt, solange das mit CUL_HM noch nicht wieder rund ist).