Page 8 of 10
Re: XMPP plugin request
Posted: Fri Feb 02, 2018 8:57 pm
by kgschlosser
I know there is a retry mechanism that has been put into place in the library I have this turned to off. but what you are seeing is the same sort of thing that i was seeing when i used port 5223. But I do know with the 5223 thing it was an issue with the encryption. So we need to find out the source of the problem.
Re: XMPP plugin request
Posted: Sat Feb 03, 2018 8:20 am
by kgschlosser
OK I think i found the problem. Try this and see if the problem is taken care of.
I also added server certificate validity checking and expiration checking.
Re: XMPP plugin request
Posted: Sat Feb 03, 2018 9:03 am
by Snowbird
Thanks, I will try it right now and will let you know what happens, if anything happens, because I got this bug only on time so far.
Re: XMPP plugin request
Posted: Sat Feb 03, 2018 9:51 am
by Snowbird
so far so good
could you please implement this XEP :
XEP-0184: Message Delivery Receipts
https://xmpp.org/extensions/xep-0184.html
Thanks

Re: XMPP plugin request
Posted: Sat Feb 03, 2018 8:20 pm
by kgschlosser
I know there are a few add-ons you would like to have running. I want to finish up the core if it before adding the "extras". I am working on handling the roster so this way you can see the current presence of other users. But also I am going to add a drop-down (editable) to the presence and message actions to list the current users. I am also going to move the "from" nickname to the plugin config dialog.
Re: XMPP plugin request
Posted: Sat Feb 03, 2018 11:55 pm
by Snowbird
ok, sounds great, can't wait to see all this :p
PS. still no issue so far
Re: XMPP plugin request
Posted: Sun Feb 04, 2018 4:56 am
by kgschlosser
I think I have the issue taken care of.. there were 2 things that were "wrong" One was there is that auto_reconnect variable in the ClientXMPP. Event tho I specified the auto retry as false the code is incorrect in the ClientXMPP because it considers anything past the opening of the socket to not be apart of the auto retry and it gets handled by the auto_reconnect. where the auto_reconnect should be reserved for when a session actually is made and then disconnects for some reason. In this cause the session is never getting made it fails before that.
The other I don't think was wrong per say. but it wasn't ideal. it was the fact that i was reconnecting on disconnect. so instead of a reconnect i send it back through the process of creating the entire connection over again this way there is a timer loops for once a second instead of blasting away at it as fast as it can. I also had it remove any log entries during this process.
So i think between the 2 this problem should be handled.
and I feel pretty good about the suspend and resume with the loop that tries to connect every second for a minute. This should handle any latency in the network connecting from a wifi card.
Re: XMPP plugin request
Posted: Sun Feb 04, 2018 8:56 pm
by kgschlosser
OK here is a new version. This is not backwards compatible with the other versions.
I moved the nickname out of the actions and into the plugin config dialog.
I also created a drop down for entering the JID in the actions. this displays all current users in the roster. If the user is not in the roster you can edit the drop down to add it. I also implemented an auto complete in the drop downs.
I added a new action GetPresence the GetPresence action provides a dropdown to select the specific resource for a JID that you want to get the presence for. This only returns the type of presence as a string. example.. away, xa, chat.....
Re: XMPP plugin request
Posted: Sun Feb 04, 2018 10:15 pm
by Snowbird
Hi,
there is a problem with the plugin configuration fields, they don't correspond to what they should be...
Nickname is >> Port
Port is >> Server
etc...
So i can't make it work for now
Re: XMPP plugin request
Posted: Sun Feb 04, 2018 11:41 pm
by Snowbird
Code: Select all
00:40:29 Exception in thread Thread-4:
00:40:29 Traceback (most recent call last):
00:40:29 File "threading.pyc", line 801, in __bootstrap_inner
00:40:29 File "threading.pyc", line 754, in run
00:40:29 File "C:\ProgramData\EventGhost\plugins\XMPPPlus\__init__.py", line 221, in _connect
00:40:29 address = (self._server, int(self._port))
00:40:29 ValueError: invalid literal for int() with base 10: '404.city'
Re: XMPP plugin request
Posted: Mon Feb 05, 2018 12:21 am
by kgschlosser
oooops...
Re: XMPP plugin request
Posted: Mon Feb 05, 2018 1:00 am
by Snowbird
ok, it works now
I noticed that in the drop down menu I can see 2 times the same account listed, the one that is configured in the plugin, the others appear just once so no problem with them.
How can I see the result of the get presence action? I didn't understand well your explanation.
Re: XMPP plugin request
Posted: Mon Feb 05, 2018 4:40 am
by kgschlosser
it returns the presence. so you would do something like so.
Code: Select all
macro
some event
get presence action
python command action
If eg.result != "chat": eg.StopMacro()
some additional actions if the presence is chat
if you simply want to view it then Add the Dump result to log action after the Get Presence action.
I was trying to think a little out of the box on this one. You can set up a an XMPP server like Openfire. if you have some devices you want to control you can add this plugin multiple times with a username for each device. you can use the presence to indicate if the device is on or off. so if you send a message to a JID (a device) the message will show up in EG you can then check the state of the device by using the Get Presence action.
So essentially through the use of IM's you can control your home. and this is cross platform (so long as you use a cross platform messenger)
Re: XMPP plugin request
Posted: Mon Feb 05, 2018 4:45 am
by kgschlosser
try this one see if it fixes that double entry of the client JID
Re: XMPP plugin request
Posted: Mon Feb 05, 2018 8:48 am
by Snowbird
kgschlosser wrote: Mon Feb 05, 2018 4:40 am
So essentially through the use of IM's you can control your home. and this is cross platform (so long as you use a cross platform messenger)
I'm glad you're finally seeing all the great possibilities of XMPP through EG, that was exactly what I was saying 3 months ago in my very first post of this topic :
Snowbird wrote: Wed Nov 15, 2017 10:29 am
The ultimate goal, is to "talk" with EG with any XMPP client (android, Windows, Linux, Mac, etc.), just run your client and send instant messages to EG, and make EG do things for you and then let EG "talk back" to your XMPP client.
So yes, that's a great plugin that could do so much to control everything, that is why I was insisting so much
Thank you !