MQTT Client

Questions and comments specific to a particular plugin should go here.
User avatar
Pako
Plugin Developer
Posts: 2294
Joined: Sat Nov 11, 2006 1:31 pm
Location: Czech Republic
Contact:

Re: MQTT Client

Post by Pako » Mon Jul 21, 2014 4:49 am

shaggy79 wrote: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

User avatar
Pako
Plugin Developer
Posts: 2294
Joined: Sat Nov 11, 2006 1:31 pm
Location: Czech Republic
Contact:

Re: MQTT Client

Post by Pako » Mon Jul 21, 2014 7:03 am

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
Experienced User
Posts: 129
Joined: Sun Jul 13, 2014 4:57 pm

Re: MQTT Client

Post by shaggy79 » Mon Jul 21, 2014 3:30 pm

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

krambriw
Plugin Developer
Posts: 2570
Joined: Sat Jun 30, 2007 2:51 pm
Location: Stockholm, Sweden
Contact:

Re: MQTT Client

Post by krambriw » Tue Jul 29, 2014 9:32 am

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
Posts: 20
Joined: Sat Nov 22, 2014 8:08 am
Location: New Zealand

Re: MQTT Client

Post by tameion » Sun Nov 23, 2014 4:34 am

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
Plugin Developer
Posts: 2570
Joined: Sat Jun 30, 2007 2:51 pm
Location: Stockholm, Sweden
Contact:

Re: MQTT Client

Post by krambriw » Sun Nov 23, 2014 10:40 am

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
Posts: 20
Joined: Sat Nov 22, 2014 8:08 am
Location: New Zealand

Re: MQTT Client

Post by tameion » Mon Nov 24, 2014 9:53 am

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
Plugin Developer
Posts: 2570
Joined: Sat Jun 30, 2007 2:51 pm
Location: Stockholm, Sweden
Contact:

Re: MQTT Client

Post by krambriw » Fri Nov 28, 2014 11:28 am

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
Posts: 20
Joined: Sat Nov 22, 2014 8:08 am
Location: New Zealand

Re: MQTT Client

Post by tameion » Sat Nov 29, 2014 3:12 am

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...

:D

krambriw
Plugin Developer
Posts: 2570
Joined: Sat Jun 30, 2007 2:51 pm
Location: Stockholm, Sweden
Contact:

Re: MQTT Client

Post by krambriw » Sat Nov 29, 2014 6:29 am

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

Kind regards, Walter

krambriw
Plugin Developer
Posts: 2570
Joined: Sat Jun 30, 2007 2:51 pm
Location: Stockholm, Sweden
Contact:

Re: MQTT Client

Post by krambriw » Sat Nov 29, 2014 5:52 pm

@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 216 times

tameion
Posts: 20
Joined: Sat Nov 22, 2014 8:08 am
Location: New Zealand

Re: MQTT Client

Post by tameion » Sun Nov 30, 2014 12:05 pm

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
Plugin Developer
Posts: 2570
Joined: Sat Jun 30, 2007 2:51 pm
Location: Stockholm, Sweden
Contact:

Re: MQTT Client

Post by krambriw » Sun Nov 30, 2014 2:39 pm

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
Posts: 20
Joined: Sat Nov 22, 2014 8:08 am
Location: New Zealand

Re: MQTT Client

Post by tameion » Tue Dec 02, 2014 5:02 am

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
Posts: 20
Joined: Sat Nov 22, 2014 8:08 am
Location: New Zealand

Re: MQTT Client

Post by tameion » Wed Dec 03, 2014 5:54 am

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

Post Reply