The Twine forums are now archived. If you need help, please visit


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?


  • 12 Comments sorted by Votes Date Added
  • Gerry,

    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. :-)

  • I'm in Ontario, and with Rogers Wireless. The TEST SMS also works for me. I can think up some reasons for why the SMS thing might not work, such as where the text originates (is it in the US) creating an issue with international text being somehow different from in country. However, that does not explain why email doesn't work.
  • I've set up a rule to email me (no SMS as I'm in the UK) and so far there's just been silence. The temp records in the dashboard but that's it, no notifications.
  • For Rogers Wireless, John Kestner has posted a solution to the SMS issue at
    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
  • I just got my twine and i'm having similar issues, I created a rule to alert me that when the temp dropped below 10 deg C it would email and text me. I haven't got either. I then created a new rule to text/email me when it got above 40 degrees C. I kept getting tons of email/ there something wrong with the code that it is triggering wrong? anyone else have these issues?

    The second rule proves it's not an email/text issue....
  • Thought I would update any who care about my problems. :)

    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.
  • @Ryan - thanks for the information, trying it now :)
  • Well, I tried with Fahrenheit as well with the rule given here :

    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
  • The documentation (such as it is) is not entirely clear, but from discussions with John Kestner on the moisture sensor, it seems that rules are implemented something like this;
    * 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.
  • Hi Gerry

    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.
  • Hi Brian and others:
    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.
Sign In or Register to comment.