publishing mqtt message issue

[Wibo]

Hi Gene,

could use some help here.

When I started reliability tests all kinds off issue came by.
Would like to start with the sending HG box.

Nmqtt is throwing exceptions as soon as I generate more then one sensor event per second.
When I let 4 sensors generate an event every second it's party time.
It's not always happening, it happened that I had to wait 30 min.
The log file is not showing the exception, you need the console.
I have tested this on RPi and win7, Rpi from command line and win7 as debugging session.
They both have the problem, although RPi is more sensitive.
CPU load on RPi and even Win7 can raise above 50% when Nmqtt is not happy.
Despite all the problems above no events seem to get lost when I'm monitoring Mosquitto broker.

Setup:
Rpi B+ based on image 431, /usr/local/bin/homegenie replaced by linux build r460 bin/debug
Win7 running r460 from VS
Mosquitto mqtt broker running on win7
Everything was down except one broker and one HG box only sending mqtt with FakeTemperatureCluster.

Already saw you're on r466 now and have made new images and installs.
As opposed to the last fix you made for me, I can now test a new revision very fast.

Attached the hgx, console and log output from a RPi session.
As a bonus an interesting one that could indicate multithreading issues.

Could start researching Nmqtt unless you have a better idea.

best regards,
Wibo.

[Gene]

Hi Wibo,

yes it could be a multithreading issue. If so add a "lock" instruction in the MQTT client app at line 140 like shown below:

Code: [Select]


// We want to do further processing whenever a module changes
When.ModuleParameterChanged( (module, property) => {
    if (module.HasFeature("MQTT.SensorPublish") && (property.Name.StartsWith("Sensor.") || property.Name.StartsWith("Status.") || property.Name.StartsWith("Meter.")) && !module.Instance.Domain.StartsWith("MQTT:"))
    {
      lock(this)
        try{
            Net.Publish(clientid + "/" + module.Instance.Domain + "/" + module.Instance.Address + "/event", Newtonsoft.Json.JsonConvert.SerializeObject(property));
        } catch  (Exception e){ Console.WriteLine("ERR:"+e.Message + "\n" + e.StackTrace); }
    }
  // returning true, will route event to other listeners
return true;
});

then click "compile" to makes changes effective.

Cheers,
g.

[Wibo]

Hi Gene,

some additional info:
I use the hgx only to generate events in the standard way by RaiseEvent.
All the rest is HG.

Activated mqtt
I publish the modules to mqtt and that's it.

You really want me to bypass the HG module publishing system and send mqtt message myself like your example is suggesting?

best regards,
Wibo.

[Wibo]

Nmqtt seems to be a dead project, last activity in 2013...

[Gene]

Wibo,

I'm suggesting to modify the MQTT client program in HG automation section.
Not to write a new one.

- Go to Configure->Automation->Interconnections
- Click on the MQTT Network program
- Click Edit and go to Program Code tab
- insert a lock(this) instruction at line 140 (like shown in the snippet of my previous message)
- click Compile

g.

[Wibo]

Hi Gene,

sorry I misunderstood.
I followed instructions and replaced the When.ModuleParameterChanged snippet.
Recompiled the MQTT client app in Configure->Automation->Interconnections.
Restarted HG, checked if the code change was still there.

Same results in the Console for RPi, duplicate key exception is still thrown and RPi is really slow.
Won't have more time this evening for testing.

Regards,
Wibo.

[Wibo]

Hi Gene,

FYI:
Made a windows forms test app for Nmqtt
No fancy code, just trying to reproduce the exception.
and yes, it's reproducible!!!

This is a Nmqtt problem, going to test some more...

Think I'll postpone my update to r466.

Regards,
Wibo.

[Gene]

Thanks for looking into this, let me know your findings about possible nmqtt fixes.
There's r471 now available, in case you want to help testing or use latest source code for debugging.

Cheers,
g.

[Wibo]

Hi Gene,

hope to post my testing report tomorrow.

Nmqtt is a very weird library.
It only seems to work in one mode and that's not the QOS guaranteed delivery.
I can accomplish very high bandwidth in the MqttQos.AtMostOnce.
The library throws exceptions on Dispose and on much more it should handle itself.

I'm not looking forward to download the source and fix it, since it's a dead project since 2013.

Is it an option to switch to another living DotNet MQTT implementation?

Regards,
Wibo.

[Gene]

Hi Wibo,

any other working MQTT implementation is welcome.

Cheers,
g.

[Wibo]

Hi Gene,

good to hear there's no sentimental value on nmqtt.
The library is very buggy and your retry mechanism is making it worse. (Retrying = burst)
There's nothing wrong with your retry mechnism, it's nmqtt that's crappy.
We all want guaranteed delivery for our messages without eating all CPU cycles.
nmqtt just can't do that without being fixed.
The receiving code has simular problems, but I didn't test as thoroughly.

Test report is attached, going to do research on alternatives...

Regards,
Wibo.

[Wibo]

Hi all,

found this untill now...

Nmqtt:
Last activity 2013 and buggy

MqttDotNet: http://www.stevenlovegrove.com/?id=37
Source: https://github.com/stevenlovegrove/MqttDotNet
Last activity july 2014

M2MQTT: https://m2mqtt.codeplex.com/
Last activity january 2015 (forum)
Last release december 2014
It has an Eclipse Public License (EPL)

KittyHawkMQ: http://www.kittyhawkmq.com/
Not open source

=================================

M2MQTT seems interesting, going to look at the source.

If there's anyone who used/researched any of the above projects, please let me know.

Regards,
Wibo.

[Wibo]

M2MQTT Source seems to be ok.

support for mqtt QOS
support for windows phone, mono and lots of other things

Code is full of ifdefs though like this:
#if !(MF_FRAMEWORK_VERSION_V4_2 || MF_FRAMEWORK_VERSION_V4_3 || COMPACT_FRAMEWORK || WINDOWS_APP || WINDOWS_PHONE_APP)

Going to test it...

Regards,
Wibo.

[Wibo]

Hi Gene,

first tests with M2MQTT are very promising all QOS modes are working.
It's very stable when stressing it, but I need better testing abilities at high bandwidth.
Have to make a testprog now that works on RPi and win7.
Also have to make a testprog for the receiving side, so I can test if any messages are lost at high bandwidth.

Will be busy for a while to see how good this library is...

Regards,
Wibo.

[Gene]

Hi Wibo,

thanks for checking this out. If your tests give an happy result, I will change the NetHelper class so to use m2mqtt that will then replace nmqtt.

Cheers,
g.