Sounds like a reasonable compromise.
Results are really good so far - these sort of close together emails used to be quite problematic for me. I'm not getting any dropped emails at all atm. 
PS. I use email to log these events for security reasons. that way if we get broken into I can show exactly when we left home, returned etc.
1 Like
Very cool collaboration, you guys. And I sit here benefitting far beyond any contribution...guilty as self-charged. 
Congrats on the progress and improvements. Really appreciate this tool.
1 Like
Never thought of that use-case. Good idea, not having to try to remember when everyday things happened is very useful. 
1 Like
This is one of those life lessons acquired the hard way - we were renting and got broken into. The problem was there was no sign of forced entry and we lived in a busy street that included a Hair Salon opposite us. As a result the street always had different cars and ppl coming and going.
Anyhoo, because there was no sign of forced entry, we had to fight the insurance company for months before they finally paid the claim. They really put us under the microscope and went thru our finances etc to make sure we didn't "rob ourselves". Not fun.
We think a previous tenant still had a key and the Real Estate agent admitted they'd never changed the locks despite managing the property for 5 years.
2 Likes
As my dad used to say, "insurance is great until you need it." 
Glad things worked out...insurance companies are not fun to go up against.
Totally off topic, but if you want to hear a really bizarre case of insurance fraud, check this podcast out. Mind-blowing.
1 Like
Insurance companies are usually pretty good in Australia as we have some very strict Consumer Protection laws - but if there's a grey area, they will try to exploit it.
1 Like
My wife and I are planning a long visit down under in a couple of years...when we arrive we'll get together for a beer and "insurance griping session."
2 Likes
I'm in Melbourne, we have some great pubs in the city I could take you to. 
2 Likes
i actually tried to do a version with a full .. queue using the state variables but aparently they are not re-entrant even though they kinda seem to be workin in this limited case..
i would put stuff in the queue. after it would show it.. and also show it when i run the initial function but when the getnextitem off of queue was called it would show empty..
bummer. have to go with this for now.. if you try to send more than 3 in a 20-30 sec range it will most likely drop one.
2 Likes
I believe the way state variables are working from my observations is that they are stored globally with the device, but when the device code gets called it is making a local copy of the state variables for you to use.. Not sure when they get rewritten to the device handler maybe on exit.
But so if i am running and i make changes to the queue fine i can see them
but in the meantime if another instance starts up (ie another email comes in) and it adds it to the queue it is only in its instance and when the first running one then finishes the email and goes to look at the queue it is not seeing the elements the other instance added.
FYI, not sure if it's applicable to Sendmail, but wanted to share that there was an update to HE Mail today that might be interesting to you.
i am not sure what the point of that is becuase the rest of the code does not really support multiple instances/emails being sent at once anyway.. It would have to be rewritten like i was trying with some sort of queueing method..
2 Likes
I agree that some sort of queuing would be a better way to go...
2 Likes
ya i am still searching for a way to implement queueing that works in a device handler with multiple instances running. you would think the state variables or attributes would but as i found out not really. Apparently they are not really true globals.. but local copies that are rewritten to the global pool at some point..
1 Like
The system is async by default. Certainly the actual sending of message code is sequential but the calling of it is not. This update tries to mitigate that by attempting to acquire a semaphore (timeout 5000 milliseconds) before sending stuff. The thinking is to try and throttle things if incoming gets too fast. Some people were getting skips - whether or not it will be effective as you mention remains to be seen.
1 Like
ok peeps new version. i have tested it with up to 10 concurrent messages
v 2.4.3 true concurrency and queueing using a thread safe data structure concurrentlinkedqueue and also mutex (thanks to erktrek)
tested with up to 10 messages
When one message finishes it checks the queue, and delivers any other remaining.. also schedules a rerun when busy and one is added to the queue.
also serialize the setting and checking of the state.lastCommand as this is used to keep track of the async status of the commands
here is the jist of it
import java.util.concurrent.Semaphore
import java.util.concurrent.TimeUnit
import groovy.transform.Field
import java.util.concurrent.ConcurrentLinkedQueue
@Field static java.util.concurrent.Semaphore mutex = new java.util.concurrent.Semaphore(1)
@Field static java.util.concurrent.Semaphore lastStateMutex = new java.util.concurrent.Semaphore(1)
@Field static lqueue = new java.util.concurrent.ConcurrentLinkedQueue()
also figured out how to have multiple concurrent runIn commands scheduled without one overwriting the other which would cause messages to be lost with the secret command:
runIn(30,"processQueue", [overwrite: false])
Lots of changes.. let me know if you see any issues.
4 Likes
Nice work!
I assume this is running ok in the new updates as I have not updated yet due to various cluster *****
regarding presence sensors and dashboard tile links..
Will give you guys some time to work out the kinks.
v 2.5 changes were enough to signify new version. Found one bug in last one when reviewing code. a synchronize inside a synchronize on same semaphore.
Did not seem to be causing issues so I assume the system is smart enough to avoid it but fixed anyway.
1 Like
