MQTT Client

[Pako]

Now I am trying to use Nmap but like I said I'm new to all this and very out my depth
I have installed the plugin but I have no idea how to "set it up" ?

I obviously glad to help.
But I need to know how far you got (from which place you do not know what to do next).
Just one basic question:
You installed Zenmap?
Please - questions related to Nmap plugin write to the appropriate topic !

Pako

[Pako]

Dear Walter,
I have (as usual when try a plugin), some comments:
1) Please - give the option to set event prefix. I think the prefix Main should not be used for plugins (except for native plugins of course)
2) In line 552 you have str(eg.ParseString(message) if message else text.empty).
This is a problem if the string contains non-ascii characters.
I think that there should be (eg.ParseString(message) if message else text.empty).encode("utf-8"). Then it works correctly.
I found out that eg (Android) program MQTT Sender also uses UTF-8 encoding.

Best regards,
Pako

[shaggy79]

Pako,
I've sent You a reply in Nmap section.
Paul.

[krambriw]

Dear Pako,

I am very happy for your valuable advice and I will in upcoming releases of my plugins always consider this from now on.

Regarding the prefix, I do fully agree with you and I will introduce a setting for this. For older plugins, I think I will however have to keep 'Main' as default because many users might have already created a lot of actions/macros.

Best regards, Walter

[tameion]

Hi Walter

Have been playing with your MQTT client for a bit now and it is really making a difference.
Can I suggest a small change to line 126 in your _init_.py file

Change: msg.topic,
To: msg.topic+"."+str(msg.payload),

This way when the Trigger event is created in EventGhost it includes the payload.
This would make event triggering the result of the payload's contents rather than the activation of the feed itself.

Ie. we used to get this : Main.Garage/Rollerdoor/A
Now we would get this: Main.Garage/Rollerdoor/A.Closed

Hmmmm even as I edit this for the third time I can see a weakness in that we would have to know what the payload was going to be in order to trigger the event.... so what about things that have less defined or random contents? Unless there is another means of getting the event trigger to reflect the payload contents?


BTW impressed with your efforts.... I tried to write my own client but failed... !

Thanks again

- Wayne

[krambriw]

Hello Wayne, thanks for reporting your experience back!

I just realize I have made a number of improvements to the plugin but I did not upload the latest. Could you try this one from 31.07.2014 ?

http://sto.hopto.org/Release/MQTT%20Client/



Best

[tameion]

Okay Walter

The new code is much cleaner .... nice work.
And I see how you have split out the feeds for Zwave, rfxtrx, & nethomeserver.

But my problem is still the same....
Your method triggers an event when the topic receives a message and publishs against the topic.
This would work perfectly with a light sensor where the topic is used to trigger the one events.
Eg. MQTT.HOTHOUSE/LIGHTLEVEL

There could be a place for having the MQTT topic + payload trigger the event
This way the payload can be used to specifically trigger the event rather than the topic alone

It''s just that when you drag an event trigger across from the log to become a macro trigger it looses anything after the topic!

I know I can capture the message payload and then write some python script to respond to the appropriate option but it would be easier to let the payload message be the trigger.

Could there be an tick box in the MQTT subscription to append incoming MQTT messages to the event trigger?
ie. MQTT.HOTHOUSE/VENTS+{eg.event.string}
would become
MQTT.HOTHOUSE/VENTS/25%


- Wayne

[krambriw]

But my problem is still the same....

Yeah, haven't changed that part yet...

I think it can work as you suggest for on/off devices events but I'm doubtful regarding devices providing a value, it is generally not good to have the value in the event string. If you want the macro to be triggered by any value you would have to have an event configured for each possible value. If you are only interested in one or a few values, this would work as you suggest.

I don't know how to separate those two use cases...if I provide an option in the subscription action this would solve it but you would then eventually have to create more subscriptions to cover all your use cases. But maybe this is not a problem?

Best

[tameion]

You're right .... its not a problem ... just an implementation issue in the end. Two different ways of dealing with the same data... lol.
I'll use the payload to trigger the event in a python script for now.... messy but it will work.

Dragging an event from the log with its payload in the title would be the best way to trigger a specific macro when there are limited possibilities .... like the state of a door. But this would not be as successful for something with unlimited payload possibilities ... like a high definition digital temperature sensor.

Why not add to the action script in your client so that you have
"Start a new MQTT subscription (Topic Trigger)
"Start a new MQTT subscription (Payload Trigger)
"Publish a MQTT message"

Both run in the same way but the second simply appends the payload to the event being displayed in the log...

[krambriw]

Good suggestion, I'll update the plugin 'asap'

Kind regards, Walter

[krambriw]

@tameion
This new beta version has a setting where you can select to merge the event string & payload into the event string. Could you try and report back if you think this is working as expected (it looks ok for me during my tests). Existing subscription actions will report error until you open them again and just click the ok button...

Kind regards

__init__.py

(26.86 KiB) Downloaded 237 times

[tameion]

Awesome work....
As the saying goes...now I can have my cake and eat it too..... !

Tests out more than okay.

- Wayne
(@Tameion)

PS. What was your intention for the extra functions you built into the code... for the Zwave, homeseer, etc?

[krambriw]

Thanks for your feedback,

What was your intention for the extra functions you built into the code... for the Zwave, homeseer, etc?

Well, maybe this was not needed but I wanted to tailor the event format a bit for those...at the end it might be they were unnecessary.

Best

[tameion]

Yeah I don't think they will be necessary
Now that we can also include the payload we can directly trigger a macro removing the need to python in a response.

If something was Homeseer or zbee specific then all they have to do is identify it in the thread!
/Myhouse/Homeseer or ?Home/Zbee/garden


Awesome work.... very very useful.

@Tameion

[tameion]

Noted one small issue that people may have...

If you do not rename your second and subsequent MQTT Client subscriptions it will conflict and neither will work.
Perhaps you need to stipulate that the title of the MQTT client subscriptions have to be different!

- Wayne