EventGhost

XMPP Plus
1.2.2b

Installation:

Download the attached file and double click to install.
Add the plugin to your configuration tree.

In the Configuration dialog you will need to enter the following.
Jabber Id (JID)
Server
Port
Resource
Nickname (optional)

The nickname is a user friendly name that gets sent along with messages and presence changes

Actions:
Send Message
Send Presence
Get Presence
Get Message
Send Message Receipt
Is Message From
Is Message Type
Is Presence From
Is Presence Type

The actions Get Message, Is Message From, Is Message Type, Is Presence From, Is Presence Type must be run inside of a macro that has been trigger by the Presence or Message event.

The Send Message Receipt action can only be used in a macro that was triggered by the Incoming.ReceiptRequest event

Events:
XMPPPlus.{SERVER}:{PORT}.Connected
XMPPPlus.{SERVER}:{PORT}.SocketError
XMPPPlus.{JID}.AuthenticationSuccessful
XMPPPlus.{JID}.RosterReceived
XMPPPlus.{JID}.SessionStarted
XMPPPlus.{JID}.SessionEnded
XMPPPlus.{JID}.Incoming.Message
XMPPPlus.{JID}.Incoming.Presence
XMPPPlus.{JID}.Incoming.Receipt
XMPPPlus.{JID}.Incoming.ReceiptRequest

{JID} = the JID you entered in the plugin config


1.2.1b changelog

Updates get presence action to return "available" and "offline"

1.2.2b changelog

Removes timeout periods on reconnecting the client.
Fixes traceback when selecting a message type in the Send Message action.

kgschlosser wrote: Sat Feb 10, 2018 6:10 am OK i miss read what you had stated.
so when EG send the message to ask for a receipt and when the receipt comes in to generate an event? it does that already.

In fact, the word "receipt" is not really adequate here, there are 2 states :
1- message Sent successfully
2- message Delivered successfully

1- When the message is Sent from the client, it means that the message has arrived to the server, and the server informs back that it has sent the message successfully to the recipient, but the server doesn't know if the recipient really received the message ! and can not inform back the client about this. (as an analogy, it acts the same as when you go to the post office to send a letter, all you know is that your letter is being taking care of and is going to be sent, but you don't know for sure if it's actually going to be delivered).

2- If the server and the recipient support the "Message Delivery Receipts" feature, then the server is informed that the message has been delivered successfully to the recipient, and then it informs back the client the same thing. (as an analogy, it acts the same way as a registered mail at the post office, the post office informs you when your letter has been delivered successfully).

So at the end we should know 2 things, that the message was sent, and that it was really delivered to the recipient. But you have addressed only the first case : Sent, when EG sends a message it generates this event Incoming.Receipt (telling us that the message was sent, but we still don't know if it was delivered.)

kgschlosser wrote: Sat Feb 10, 2018 6:10 am so now what takes place is
When you send a message with the box checked off for getting a receipt. you should get a an event Incoming.Receipt if the message was delivered properly.
if you get an Incoming message that if requesting a receipt. you will get 2 events. Incoming.Message and another Incoming ReceiptRequest

While it's not a bad thing to have, I didn't ask for this I was probably not very clear in my initial request, let me try to rephrase it.
When EG sends a message to a recipient, if the message was sent successfully then EG should raise an Event : MessageSentSuccessfully, afterwards if the message has been successfully delivered to the recipient, it should raise another Event : MessageDeliveredSuccessfully.

What you did is the other way around, ie, when EG receives a message it generates an event ReceiptRequest, and then another one Receipt. As I said, it's nice to have, but it's not what I asked for and by the way, by doing this you broke something ! on my android client I don't see the Delivered status anymore I only see the Sent status, it was working perfectly with your previous version 1.1.0, please fix this.

you asked for the xep-0184 plugin

my first release with this would work in this manner. when you get the receipt event it means the message was delivered successfully.

then you asked to get it so it was the other way around.

so I now created an event when the sender is asking for a receipt.

as per your description above I have provided what you wanted the first time around


the receipts not being received by your android client are not broken. you are simply not sending them. as per the instructions in the first post you need to take the event for the receipt request and place the action Send Receipt into the same macro. this allows you to choose if you want to send one or not.

and you know that message has been sent and the server received it if no error occurs upon sending the message from EG

ok, great then, I must admit that I didn't understand the logic behind it in the first place, and now that I have understood, not only it seems logic but it also works I'm very sorry for the misunderstanding !

good job !

No worries. as long as we are both on the same page. I didn't know if I was making an error in my understanding.

The reason for the ability to choose whether to send a receipt or not from EG using that action is I thought it would be useful as a reply for a sucessfull command execution. No receipt means the command didn't execute. with EG so long as there is a connection to a server you can guarantee the message was sent and the server has it. if you get an error in EG then you know the connection to the server is toast. and requesting the receipt is the second leg of the journey. from the server to the recipient. Now I can if you want me to add a roster update to verify the user is connected and has a presence of Available or Chat and return a True/False based on this. Then you can use the jump if from there to pick which set of macros to run.

No, I think that's fine as it is, thanks.

If you feel like it, and if it's not too much work for you, you could add this XEP :
https://xmpp.org/extensions/xep-0280.html

It's nice to have all the messages on every different devices using the same xmpp account.

Hi,

any progress on this ?

Snowbird wrote: Sun Feb 11, 2018 11:54 pm If you feel like it, and if it's not too much work for you

Well since i state it how it is... I have not felt like it.. and it's work. and if it's work it's always to much.

I'm messin with ya. I have not done anything with it as of yet. Been working on a revamp of the audio controls in EG and it's a pretty large undertaking, about 10,000 lines of code thus far. and poking about fixing glitches in other plugins I have made.

LOL I must admit that you scared me at first, then I laughed ! :p

No worries, there's no rush at all, everything is working just fine, it's just an extra feature to have. All I'm asking is not to forget me I have already experienced this on my very old request about the "4 LED icons" plugin, it would be nice not to relive this bad experience

Hi,

I have noticed something annoying, and observed it a couple of times. When the remote server restart the XMPP server, the EG client obviously goes offline since it can't connect, but when the server is available again, the EG client doesn't reconnect automatically, it stays offline until I completely restart EG. I've tried to disable the plugin for 30 seconds before re-enabling it, but it doesn't work. Is there an auto reconnect mechanism ?

There is but this mechanism only works for 60 seconds. if the server is down beyond that then you should be able to r4estart the plugin.

I will add a means to keep on trying to reconnect if the plugin was already connected.

kgschlosser wrote: Mon Feb 26, 2018 6:00 am There is but this mechanism only works for 60 seconds. if the server is down beyond that then you should be able to r4estart the plugin.

What you're saying didn't work, if the server was down for less than 60 seconds then it should have reconnected on its own, this wasn't the case, and on the other hand if the server was down for more than 60 seconds then I should have been able to restart the plugin to make it reconnect, and it it didn't work either... so either I misunderstood your explanation, or there's something not working as expected.

kgschlosser wrote: Mon Feb 26, 2018 6:00 am I will add a means to keep on trying to reconnect if the plugin was already connected.

ok fine, it would be nice if you could also add 2 events, one when the connection to the server is lost, and one when the EG client has reconnected successfully, this will serve 2 purposes, we will know when the server is down, and we could add some actions when this happens.


Thanks !

I have just noticed that the "Get Presence" action doesn't work for the "Available" status, it returns nothing, the strange thing is that it works for all other statuses (Away, DND, XA, etc.). Could you please check this ?

Also, since I'm still having some disconnections from time to time (because of server maintenance), the mechanism you described earlier doesn't seem to kick in, restarting the plugin doesn't reconnect to the server either, the only way is to restart EG, I'm kind of stuck... so maybe adding an action to disconnect/reconnect would be useful in this circumstance, I would detect manually when a disconnection from the server occurs, and I would run those action to re-establish the connection.

Thanks

the Available status is an internal status. I thought we kind of went over this already with the Available.

yeah I thought we covered this.

viewtopic.php?p=50010#p50010

what I can do is if there is a no answer returned then I can return an Available. But i would need you to confirm that you do not get a no answer if you are offline. if more then one of the presences return a nothing answer then I am not sure of how I would go about getting the proper answer back.