Home › General › Miscellaneous
Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
The Twine forums are now archived. If you need help, please visit http://help.supermechanical.com
Notifications?
I have now waited more than a hour after setting up notifications for a temperature transition, and a water sensor transition, using both SMS to an iPhone, and email. Neither has worked. Both the phone number and the email address are in Canada. Is this an issue?
Answers
I'm in Newfoundland and on Koodo. The TEST SMS message works but my Rule for when my Twine is bottom up to text me does not text me.
You are not alone. :-)
Craig
http://help.supermechanical.com/kb/using-twine/text-messages-arent-being-received
Other Canadian telco's may be implementing a similar SMS gateway for which you need to set up permissions. Search your provider's web site for the need to set up permissions. (I think this is a holdover from when text was limited and expensive, the notification message was a system message and free, and you could then decide if you wanted to pay to receive the actual text. Obsolete these days, but there's nothing pushing the telco's to spend money to change it.)
Still no luck getting email, however
The second rule proves it's not an email/text issue....
Just got word it is a bug with using Celsius, apparently if you switch to Fahrenheit it will work fine, Bug should be fixed this week some time.
and I got only one notification (when the rule is saved)... whereas I understand I should get one every 15 minutes.
I am calling a website which sends an email with the temperature
* they are transition-based, not state-based;
* if you set a rule that is to do something when the temp goes below 10 Celsius, then when that happens, it executes the actions;
* after the "reset" period expires, it looks at the sensor again, and if it is still below the trigger point, it does nothing;
* if it is above the trigger point, the rule resets, and if it then goes below again, does the actions again
!Not exactly what might be expected, but again, seemingly forced by the extreme need to save battery power, and sending HTML to your wireless router costs power.
It's perhaps clearer with the moisture sensor or the mag switch. If your normal state is dry or open, then you get notification, or whatever, when that changes. But, if it stays wet or closed, you hear nothing until the state first goes back to dry or open, and then goes back to wet or closed.
That is not how most of us want the thing to work. Eg, I want to monitor a sump with a pump, so want to know when the sensor goes wet. I'd also like to be able to set a period after which I get another notification if it is still wet, and, I'd probably like to know when it goes dry - that would let me bug whoever I've called to fix the problem.
Some of it, as I've said, is the result of needing to conserve power, which drives how the sensors work and are monitored. One wishes that an early design decision had been to go with AA batteries, and a slightly larger case, or even 9 V. With less need to save power, and a "rules language" which would let your write stuff like this:
$start [moisture rules];
if &moisture was "dry" and is now "wet" then email to and to ;
if &moisture has been "wet" for greater than 1 hour then email to and repeat every 1 hour;
if &moisture was "wet" and is "dry for more than 15 minutes then email to and reset [moisture rules];
$end [[moisture rules];
But what is obvious is that we early adopters are part of a brave "proof of concept" exercise with what is probably Twine Beta 0.1. By the end of the exercise, we may have Twine 1.0, which will still be a pretty limited device. What is also obvious from these forum discussions is that most of us didn't know that is what we were going to be doing.
I think at Twine 2.0 it could get to interesting and actually useful. I see that as still having the easy connectivity, but some sort of rules scripting that is very flexible, and loses the notion of sensors using a limited length cable, with a limit of one connector. Sensors that can be one of "on/off" or sending analogue values. And if connection is wired, how about USB, with sensors self-powered by batteries and/or cheap USB chargers, with the full possibility of plugging in multiple sensors via an internal hub, and allowing external hubs to expand numbers of sensors. Or lets dream wireless, which after all Twine was supposed to do, liberate us from wires; sensors connected to Twine by Bluetooth. And lest you think that's a dream, I have in my hand right now a Garmin GPS receiver, rechargeable by USB and good for about half a day, and if plugged in powered by USB. When connected to an iPhone or Android (with a required app installed) by Bluetooth, this gadgets sends, every second, a very exact location (latitude, longitude, altitude) and relevant other information, such as time and accuracy of location. The iPhone automatically uses this in place of its internal location calculation, and you can do with it whatever.
I was having issues on getting intermittent texts and emails & posted a question yesterday about it. I then saw your similar issue.
I also sent a note to supermechanical support and they almost immediately responded that the firmware version I had was from October and there was a November 15th version that should fix this issue. It took about a day for them to update my firmware but after they did today I will now always get my texts & emails.
To see the firmware version there is a trick in the dashboard to hover over your Twine Name in the upper left and it will show you what firmware you are running. If you have more than one Twine make sure you are hovering over the correct one.
Just wanted to let anyone know who is having issues with getting notifications some of the time this worked well for me. I plan on using one of the Twines for monitoring a sump pump so getting messages consistently is important to me.
From an email exchange with John Kestner I learned the following:
there are two kinds of firmware for the Twine;
1) that which runs the Twine itself; sensor checking, rules execution, regular communications with Twine "Central" and updating dashboard info - this firmware is checked and updated if necessary every time you make a rule change and upload it;
2) the communications firmware itself, ie, the low-level stuff running the interfacing to your router, the IP address on your network, leasing an address and renewing the lease as required by your router, the issuing of HTML commands to send e-mail etc, all that is separate from the above, and is updated by "push" from Supermechanical". If you are having communications problems it is worth reporting this to Supermechanical, as they can check your communications firmware remotely, and update it if necessary.