joeharrison714 / fpp-sms-control-too

0 stars 1 forks source link

Is an update needed for FPP 7.x? #4

Open Alan440 opened 1 year ago

Alan440 commented 1 year ago

I cannot make the SMS Control Too plugin save any configuration information in Falcon Player 7.1. All entries simply vanish on restart or reboot.

I tried it with FPP 5.5 and it saves everything.

Is some update needed to work with FPP 7.1?

Thanks!

Alan440 commented 1 year ago

Based on some additional reading, it looks like the absence of fppjson.php in FPP 7.x might be the cause.

104Zero commented 1 year ago

Second this one! Would love to see it compatible with 7.x

joeharrison714 commented 1 year ago

I will look into this ASAP!

Alan440 commented 1 year ago

Hi Joe,

Glad to see your response regarding FPP 7.1. This is the first time I’ve looked into FPP plugins. The SMS control is perfect for us, since we have a large layout that’s best viewed from 150-200 feet away. WiFi isn’t useful, but SMS is great for testing and shows for guests.

I dropped back to FPP 6.3 in order to use SMS Control Too. I had a couple of other fatal issues unrelated to the new scheme they’re using in FPP 7.x.

Any text, sent one time, was executed after every sleep cycle, forever. It would play five seconds of the commanded playlist, then interrupt and play it again every five seconds, forever. The plugin also failed to discern the youngest message on the DID at voip.ms, and failed to discover messages older than 20 seconds.

I’m not a programmer, though I can understand code to a certain extent. I found the time testing routine in sms-control-bg.php. After several days of study, Googling php (which I’d never seen before), and scratching my head, I finally realized there’s a time zone issue. I live in US/Central time, but voip.ms stamps all messages in Eastern time. This caused the $diffInSeconds value to calculate to a negative number nearly 3600 seconds old. I first just added 3600 seconds, but there were other problems that this didn’t seem to solve. I eventually came across a statement to make the program deal with all time values in Eastern time. I inserted it at the top of the file and solved some of the trouble. Resetting the FPP time zone to Eastern time did not help.

That fixed the failure of the test for messages older than $sleepTime * 4. But it still restarted a sequence every 5 seconds. After driving myself around the bend troubleshooting $lastProcessedMessageDate, I discovered that the problem was in the sendSMS portion of the code. It was failing, causing an exception that made the try-catch routine in processMessages execute, thereby skipping the update to $lastProcessedMessageDate. Out of ideas, I commented out all of the sendSMS lines and that solved the repetition problem.

I wondered whether there was a problem passing variable(s) from processMessages to processMessage (if I recall the function names properly). The function call in processMessages was processMessage ($item), if I recall, but the actual function was processMessage($smsMessage) or something similar; I’m not sure I remember the exact variable. I tried some experiments with the two variables, but failed. That’s when I punted and commented out the sendSMS lines.

So as of last night, I have a band-aided version of the code that works properly. Looks like an update needs to deal with time zone differences, fix the sendSMS portion, and be able to save the user configs in FPP 7.x.

Thanks for taking a look!

Best regards,

Alan

From: Joe Harrison @.> Sent: Wednesday, October 18, 2023 8:32 AM To: joeharrison714/fpp-sms-control-too @.> Cc: Alan440 @.>; Author @.> Subject: Re: [joeharrison714/fpp-sms-control-too] Is an update needed for FPP 7.x? (Issue #4)

I will look into this ASAP!

— Reply to this email directly, view it on GitHub https://github.com/joeharrison714/fpp-sms-control-too/issues/4#issuecomment-1768468187 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ATAHEL5B4YETHDGIJWQVSGTX77K3PAVCNFSM6AAAAAA5ZSZVS6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRYGQ3DQMJYG4 . You are receiving this because you authored the thread.Message ID: @.***>

-- This email has been checked for viruses by AVG antivirus software. www.avg.com

joeharrison714 commented 12 months ago

@104Zero @Alan440 I believe I fixed the most pressing issues to make this compatible with FPP 7. If you could try it out and let me know I would appreciate it. Also @Alan440 can you share you fixes for the other issues you mentioned?

joeharrison714 commented 12 months ago

@Alan440 I just pushed an update for the timzone issues. If you could try that out too, that would be great. Also, I'd like to understand more the exception happening in sendSms so I can fix that as well.

Alan440 commented 11 months ago

Hi Joe,

I flashed a new install of FPP 7.1. I installed SMS-Control-Too using the FPP plugin manager.

The plugin installation was successful, but FPP did not echo anything; no prose about cloning from GitHub, nor any installation confirmation--just a blank window. It looked like the install had failed, but it was OK once I closed the window.

SMS-Control-Too successfully saved all of the config data under FPP 7.1. This works!


Regarding time zones:

In the previous release, I don't recall with complete certainty which issue caused which symptoms. I went through three stages with it: (1) no SMS ever executed, (2) one SMS executed endlessly, once after every sleep cycle, and (3) one SMS executed three times in a row. IIRC, the Eastern/Central time zone problem caused all SMS commands to fail because they were dated nearly an hour in the past. I think the triple-execution was caused by the sendMessage exception, which caused $lastProcessedMessageDate to not be updated; therefore, messages were always younger than $lastProcessedMessageDate, so they were executed repeatedly until they were older than $oldestMessageAge.

This is the statement I had added to the previous release that fixed the time zone issue:

 date_default_timezone_set('America/New_York');

I placed it at the top of the file, just below the line that defines $oldestMessageAge.

I believe you have now fixed the time zone issue, but in the new release, condition (3) above still exists.


Regarding the sendMessage exception:

The updated plugin still acts repeatedly on a given text message it finds on voip.ms, until the maximum age limit of $oldestMessageAge ( = $sleepTime * 4) is met. In practice, this means that each SMS command is still executed three times. It takes about 5-7 seconds on average for each text to be retrieved and executed. Therefore, the plugin properly executes the SMS on the first cycle after the SMS is sent. Then it executes it again--usually twice more--before the 20-second $oldestMessageAge becomes true. Each successive execution interrupts the prior one, so a sequence plays for five seconds, then restarts and again plays for five seconds, then restarts a third time and plays normally.

I believe this is caused by an exception, generated by sendMessage statement(s), which causes $lastProcessedMessageDate to not be updated.

I don't know what was amiss with the sendMessage lines in the previous release--it was beyond my understanding. Some problem caused the try-catch in processMessages($messageResponse) between lines 198 and 208 to fail to update $lastProcessedMessageDate. It looks to my amateur eye like sendMessage is a function call, but I don't see the function itself. Perhaps it's in another program module or file, but regardless, something is broken when the plugin goes through the sendMessage lines in the function processMessage($smsMessage), beginning at line 270 in the previous release.

My ultimate solution in the previous release was to comment out each sendMessage line. That stopped the exceptions and allowed $lastProcessedMessageDate to update.


Sorry for the wordiness! It's difficult for me to describe this accurately and clearly. I hope this is better organized than my other posts....


One other trivial thing:

It wasn't obvious to me which voip.ms username was needed as the API username in the plugin. It requires your customer portal username (your email address), not your SIP/IAX Main Username. It might be helpful to parenthetically prompt for the customer portal username in the plugin setup screen, in addition to API username.


Thanks for all your effort! This is a great plugin.

From: Joe Harrison @.> Sent: Sunday, October 29, 2023 9:53 AM To: joeharrison714/fpp-sms-control-too @.> Cc: Alan440 @.>; Mention @.> Subject: Re: [joeharrison714/fpp-sms-control-too] Is an update needed for FPP 7.x? (Issue #4)

@Alan440 https://github.com/Alan440 I just pushed an update for the timzone issues. If you could try that out too, that would be great. Also, I'd like to understand more the exception happening in sendSms so I can fix that as well.

— Reply to this email directly, view it on GitHub https://github.com/joeharrison714/fpp-sms-control-too/issues/4#issuecomment-1784135483 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ATAHEL6YA4U7IIEQQO5GFB3YBZUVTAVCNFSM6AAAAAA5ZSZVS6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBUGEZTKNBYGM . You are receiving this because you were mentioned. https://github.com/notifications/beacon/ATAHEL46C6LKP4NAZC4RB6DYBZUVTA5CNFSM6AAAAAA5ZSZVS6WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTKK67TW.gif Message ID: @. @.> >

-- This email has been checked for viruses by AVG antivirus software. www.avg.com

bigmike0640 commented 10 months ago

Love this plugin! Using it to make my show interactive. I'm on 7.3.1, and I can see in the log that the messages are being received, but no action is taken and sender gets no response. Maybe because "Message older than oldest age". How do I fix this?

Croll12715 commented 9 months ago

I'm not trying to hijack here, but is there a way to display the received message on the pixel overlay? I see the ability to add text to the overlay via command, but that is specific text, can we pass the $item variable to it?