JavaLaurence

I'm wondering what level of interest there is for a 100% software equivalent of the Tinkerforge Bricklets. For example, using simulated components, you could write stack control logic using components you don't yet physically own. Or you could do exploratory "what if" development, without actually purchasing hardware. The software-simulated components would have on-screen visualizations so that you can feed simulated sensors fake input values (e.g. with a slider), or see the output of non-input Bricklets (e.g. to see the output state of a Dual Relay).

Does Tinkerforge have approximate statistics (%) for how popular the different language bindings are? I'm curious how the current language spectrum is divided up.

(correction) .. make that last API call Thread.sleep().

After re-reading what you wrote a few times (yes, I'm afraid your English is poor), I think I understand what you mean. I'm afraid the core issue is how to coordinate multiple threads. The enumeration callbacks are called on a different thread than your own application thread. The callbacks are performed by a thread that is started by the Tinkerforge framework. There are two approaches to solve the problem: a) the hack: include a hard-coded delay of a few seconds b) the proper way: use proper thread synchronization (e.g. using wait/notify, or any of the higher level concurrency mechanisms in java.util.concurrency). The hack will probably be OK, and is just a matter of calling Thread.delay(). HTH

When a Java compiler or IDE cannot find a class or package, you typically need to add a JAR (Java Archive) file to your project's build path (or CLASSPATH, depending on the environment you use). So like batti explained, you need to download Tinkerforge's JAR and tell BlueJ to use it in your project.

Enumerating a stack configuration does not require user interaction. What is your issue with System.out.readXXX ?

Am running the new code, and the problem seems to be gone. Thanks guys!

OK, let me then turn the tables for a brief moment. I'm suspecting that TinkerForge gear attracts a lot of people to your products because they are so damn simple to click together and program. You must be attracting a fair proportion of people with little or no electronics experience, like myself. So why doesn't TinkerForge sell its relay bricklets with built-in protection against this, apparently inevitable, reality of electronics? Your docs hint/warn at the problem, but what most customers would probably prefer is simply that the problem goes away.. while keeping the click-and-play simplicity of TinkerForge kit. Any chance of a Dual Relay revision with built-in varistor?

Hi, To try and get round the now-and-again problem of my stack locking up (not just crashing, but totally locking up), I plugged my stack's power-supply in an IKEA 2 euro timer switch. Every 6 hours, I let the timer switch cut the power for 30 mins, thus ensuring that my stack is (hard) reset every 6 hours. I thought that the TF API auto reconnect feature would ensure my controlling program would be able to reconnect to my stack every time, albeit after trying for 30 minutes each time the stack power is cut. Unfortunately, my program fails to auto-reconnect most of the time. I'm attaching a screenshot of the Eclipse debugger showing the main thread suspended .. to show what it is doing. The thread always appears to be waiting on a socketMutex. Could this be a bug? Or am I missing something else? Thx.

Forgive me for my ignorance of electronics, but I thought I understood that the inductive load problem boils down to a brief (ns?) Voltage spike generated by the (AC-powered) pump, which travels along the wires to affect the power supply input to the stack, i.e. the Step-Down brick. Am I wrong in this understanding? If I am wrong, please could you explain how my stack crashes (sometimes) when the pump is switched off?

The documentation for the Dual Relay warns that switching inductive loads may require external protection of the stack. Having tried, and failed, to find a shop that can sell me a suitable varistor, I think that it would help future customers if the Step Down Power Supply contained one or more of these things. There appears to be physical room left on the board for at least one. If this idea is a non-starter, then maybe it would be nice if the online documentation could be enhanced to contain instructions for non-electronic buffs on how to protect stacks that switch inductive motors..

Can a Master detect that it has been reset due to the watchdog? If so, it would be great if that information could be brought to the surface via an API..

Yep, definitely looks like a copy-paste error.

@Borg: many thx for the new 2.0.6 Master firmware. I've installed it in my stack... but would it be possible to add some online docs for the new feature? Searching the TF site doesn't come up with anything for "watchdog".

@CD108: After doing some reading on your varistor suggestion, would the use of a simple surge-suppressing power strip not be the quickest solution (assuming I've got such a strip lying around) ? 2nd question: my Tinkerforge stack is powered with a Step-Down Brick that is fed by the DC output of a little AC-DC transformer. Are these two components transparent for a surge? I would have thought (with my naive electronics knowledge) that a Step-Down should be able to block any surges, if providing stable Voltage is one of its key functions.

Any chance of an English summary on what's being discussed in the German thread? I may be interested in buying a few weather stations as gifts (I would prefer transparent plastic).

That's what I suspected. This means that the SPI Master is a bottleneck.. the taller the stack, and the more Bricklets, the more this one Master is going to have to crunch packets. If that Master also has its full complement of four Bricklets to deal with.. at what point do the demands of the controlling application place such a load that TimeoutExceptions start to surface? As a user, I can't profile stack-side code, so I have no idea what level of CPU loading is generated.. (wouldn't it be nice if.... ;-) My polling rate is only 1Hz, but I sample all my input Bricklets without pausing between each getXXXX(). Maybe this "burst" approach doesn't help?

:)

My apologies, didn't see that one... ! :-[

The log below shows the stack running almost 24 hours without the (admittedly) horror cable I made, and without the physical LCD attached. So those elements are taken out of the equation. Whenever any exception occurs you get an exception summary line (without stack trace info) starting with a [n(x/y)] prefix. The n is just tracking how many exceptions occurred in total. The x and y are more interesting: y means that the stack has suffered y DIFFERENT exceptions up to that point, and x is an exception type. So when my BrickletDistanceIR getDistance() call blows with a TimeoutException, that's one type of exception. When my BrickletDualRelay getState() call blows, that's another type. So from the log you can see that the code sees four different kinds of exception. The log also shows that the program mostly sees exception kind #1... and that's always the Distance IR getter. Statistically, I think this is really saying something.. but what? That Distance IR is some kind of problem element in the configuration? Anyway, we're digressing again. My hope was that TF adds a top-level auto-stack resetting mechanism. Any chance of that? :'( Starting Cellar Water Pump Control System @ Tue Mar 26 21:06:46 CET 2013 Running on Java 1.7.0_04 hosted by Mac OS X 10.7.5 Initializing TinkerForge stack.. Aha. Connected @ 20:06:46 because: CONNECT_REASON_REQUEST Done. [1(1/1)] Ouch.. exception @ Tue Mar 26 21:23:25 CET 2013 Switching pump ON @ Tue Mar 26 21:36:47 CET 2013. Time since last: 21:36:47,551. Air: 1010.84,Temp: 12.62,Humid: 71.7,Light: 0.0,Heap: 3.53 MB, [2(1/1)] Ouch.. exception @ Tue Mar 26 21:52:32 CET 2013 Switching pump ON @ Tue Mar 26 22:12:28 CET 2013. Time since last: 00:35:40,947. Air: 1010.84,Temp: 12.43,Humid: 68.4,Light: 0.0,Heap: 2.22 MB, [3(2/2)] Ouch.. exception @ Tue Mar 26 22:21:57 CET 2013 [4(1/2)] Ouch.. exception @ Tue Mar 26 22:37:03 CET 2013 Switching pump ON @ Tue Mar 26 22:49:15 CET 2013. Time since last: 00:36:47,106. Air: 1010.72,Temp: 12.31,Humid: 67.0,Light: 0.0,Heap: 2.04 MB, [5(1/2)] Ouch.. exception @ Tue Mar 26 22:53:15 CET 2013 [6(1/2)] Ouch.. exception @ Tue Mar 26 22:58:22 CET 2013 [7(1/2)] Ouch.. exception @ Tue Mar 26 22:59:35 CET 2013 [8(1/2)] Ouch.. exception @ Tue Mar 26 23:26:47 CET 2013 Switching pump ON @ Tue Mar 26 23:27:23 CET 2013. Time since last: 00:38:08,365. Air: 1010.64,Temp: 12.18,Humid: 67.8,Light: 0.0,Heap: 1.46 MB, [9(1/2)] Ouch.. exception @ Tue Mar 26 23:38:37 CET 2013 Switching pump ON @ Wed Mar 27 00:06:27 CET 2013. Time since last: 00:39:04,013. Air: 1010.62,Temp: 12.12,Humid: 67.1,Light: 0.0,Heap: 1.82 MB, [10(1/2)] Ouch.. exception @ Wed Mar 27 00:40:57 CET 2013 Switching pump ON @ Wed Mar 27 00:46:28 CET 2013. Time since last: 00:40:00,082. Air: 1010.58,Temp: 12.06,Humid: 67.3,Light: 0.0,Heap: 1.68 MB, [11(1/2)] Ouch.. exception @ Wed Mar 27 01:08:24 CET 2013 Switching pump ON @ Wed Mar 27 01:27:32 CET 2013. Time since last: 00:41:04,892. Air: 1010.40,Temp: 11.93,Humid: 67.9,Light: 0.0,Heap: 993.01 KB, Switching pump ON @ Wed Mar 27 02:10:12 CET 2013. Time since last: 00:42:39,914. Air: 1010.13,Temp: 11.87,Humid: 67.9,Light: 0.0,Heap: 3.05 MB, [12(1/2)] Ouch.. exception @ Wed Mar 27 02:47:25 CET 2013 Switching pump ON @ Wed Mar 27 02:52:54 CET 2013. Time since last: 00:42:41,323. Air: 1009.86,Temp: 11.81,Humid: 67.3,Light: 0.0,Heap: 1.93 MB, [13(1/2)] Ouch.. exception @ Wed Mar 27 02:55:19 CET 2013 [14(3/3)] Ouch.. exception @ Wed Mar 27 03:05:07 CET 2013 [15(2/3)] Ouch.. exception @ Wed Mar 27 03:36:57 CET 2013 Switching pump ON @ Wed Mar 27 03:36:58 CET 2013. Time since last: 00:44:04,375. Air: 1009.69,Temp: 11.75,Humid: 67.9,Light: 0.0,Heap: 871.14 KB, [16(4/4)] Ouch.. exception @ Wed Mar 27 03:39:14 CET 2013 [17(1/4)] Ouch.. exception @ Wed Mar 27 03:41:17 CET 2013 Switching pump ON @ Wed Mar 27 04:22:02 CET 2013. Time since last: 00:45:03,828. Air: 1009.44,Temp: 11.68,Humid: 66.7,Light: 0.0,Heap: 817.41 KB, [18(1/4)] Ouch.. exception @ Wed Mar 27 04:40:45 CET 2013 [19(1/4)] Ouch.. exception @ Wed Mar 27 04:56:05 CET 2013 [20(2/4)] Ouch.. exception @ Wed Mar 27 05:03:11 CET 2013 Switching pump ON @ Wed Mar 27 05:08:32 CET 2013. Time since last: 00:46:29,773. Air: 1009.41,Temp: 11.62,Humid: 65.9,Light: 0.0,Heap: 1.77 MB, [21(1/4)] Ouch.. exception @ Wed Mar 27 05:10:51 CET 2013 [22(1/4)] Ouch.. exception @ Wed Mar 27 05:32:41 CET 2013 [23(1/4)] Ouch.. exception @ Wed Mar 27 05:54:30 CET 2013 Switching pump ON @ Wed Mar 27 05:54:32 CET 2013. Time since last: 00:46:00,707. Air: 1009.53,Temp: 11.56,Humid: 67.7,Light: 0.0,Heap: 894.96 KB, [24(1/4)] Ouch.. exception @ Wed Mar 27 06:05:22 CET 2013 Switching pump ON @ Wed Mar 27 06:41:27 CET 2013. Time since last: 00:46:55,102. Air: 1009.57,Temp: 11.56,Humid: 67.3,Light: 0.0,Heap: 2.50 MB, [25(1/4)] Ouch.. exception @ Wed Mar 27 06:46:49 CET 2013 [26(1/4)] Ouch.. exception @ Wed Mar 27 06:47:53 CET 2013 [27(1/4)] Ouch.. exception @ Wed Mar 27 07:03:10 CET 2013 Switching pump ON @ Wed Mar 27 07:27:24 CET 2013. Time since last: 00:45:56,023. Air: 1009.77,Temp: 12.12,Humid: 71.3,Light: 0.0,Heap: 1.70 MB, [28(1/4)] Ouch.. exception @ Wed Mar 27 08:03:32 CET 2013 [29(1/4)] Ouch.. exception @ Wed Mar 27 08:06:55 CET 2013 Switching pump ON @ Wed Mar 27 08:11:26 CET 2013. Time since last: 00:44:02,398. Air: 1009.71,Temp: 12.06,Humid: 67.9,Light: 0.0,Heap: 3.20 MB, [30(1/4)] Ouch.. exception @ Wed Mar 27 08:36:28 CET 2013 Switching pump ON @ Wed Mar 27 08:50:33 CET 2013. Time since last: 00:39:06,717. Air: 1009.87,Temp: 12.31,Humid: 69.4,Light: 0.4,Heap: 1.93 MB, Switching pump ON @ Wed Mar 27 09:31:27 CET 2013. Time since last: 00:40:54,876. Air: 1009.88,Temp: 12.50,Humid: 73.0,Light: 2.0,Heap: 2.25 MB, [31(1/4)] Ouch.. exception @ Wed Mar 27 09:50:20 CET 2013 [32(1/4)] Ouch.. exception @ Wed Mar 27 10:09:46 CET 2013 Switching pump ON @ Wed Mar 27 10:13:37 CET 2013. Time since last: 00:42:09,026. Air: 1009.66,Temp: 12.68,Humid: 80.1,Light: 6.3,Heap: 3.97 MB, [33(1/4)] Ouch.. exception @ Wed Mar 27 10:41:22 CET 2013 [34(1/4)] Ouch.. exception @ Wed Mar 27 10:54:28 CET 2013 Switching pump ON @ Wed Mar 27 10:57:08 CET 2013. Time since last: 00:43:31,044. Air: 1009.50,Temp: 12.87,Humid: 79.7,Light: 1.7,Heap: 1.07 MB, [35(1/4)] Ouch.. exception @ Wed Mar 27 11:27:12 CET 2013 Switching pump ON @ Wed Mar 27 11:43:34 CET 2013. Time since last: 00:46:26,135. Air: 1009.06,Temp: 13.06,Humid: 75.8,Light: 0.9,Heap: 2.21 MB, [36(1/4)] Ouch.. exception @ Wed Mar 27 11:50:32 CET 2013 Switching pump ON @ Wed Mar 27 12:29:38 CET 2013. Time since last: 00:46:04,445. Air: 1008.70,Temp: 13.06,Humid: 68.2,Light: 0.8,Heap: 2.01 MB, [37(1/4)] Ouch.. exception @ Wed Mar 27 12:46:15 CET 2013 Switching pump ON @ Wed Mar 27 13:19:09 CET 2013. Time since last: 00:49:30,626. Air: 1008.40,Temp: 12.93,Humid: 68.4,Light: 0.1,Heap: 858.89 KB, [38(1/4)] Ouch.. exception @ Wed Mar 27 13:30:31 CET 2013 [39(1/4)] Ouch.. exception @ Wed Mar 27 13:37:51 CET 2013 Switching pump ON @ Wed Mar 27 14:09:10 CET 2013. Time since last: 00:50:00,793. Air: 1008.01,Temp: 12.68,Humid: 65.8,Light: 0.0,Heap: 3.15 MB, Switching pump ON @ Wed Mar 27 15:00:10 CET 2013. Time since last: 00:51:00,169. Air: 1007.90,Temp: 12.56,Humid: 66.8,Light: 0.1,Heap: 2.55 MB, [40(2/4)] Ouch.. exception @ Wed Mar 27 15:44:05 CET 2013 Switching pump ON @ Wed Mar 27 15:51:17 CET 2013. Time since last: 00:51:07,372. Air: 1007.82,Temp: 12.43,Humid: 70.8,Light: 0.0,Heap: 1.84 MB, [41(1/4)] Ouch.. exception @ Wed Mar 27 16:07:45 CET 2013 Switching pump ON @ Wed Mar 27 16:39:50 CET 2013. Time since last: 00:48:33,390. Air: 1007.76,Temp: 12.31,Humid: 68.5,Light: 0.0,Heap: 3.21 MB, [42(1/4)] Ouch.. exception @ Wed Mar 27 16:41:34 CET 2013 [43(1/4)] Ouch.. exception @ Wed Mar 27 16:45:02 CET 2013 Switching pump ON @ Wed Mar 27 17:29:57 CET 2013. Time since last: 00:50:06,953. Air: 1007.84,Temp: 12.31,Humid: 69.3,Light: 0.0,Heap: 2.70 MB, [44(1/4)] Ouch.. exception @ Wed Mar 27 17:32:09 CET 2013 Switching pump ON @ Wed Mar 27 18:19:12 CET 2013. Time since last: 00:49:14,987. Air: 1007.91,Temp: 12.43,Humid: 70.5,Light: 0.0,Heap: 2.94 MB, [45(1/4)] Ouch.. exception @ Wed Mar 27 18:26:03 CET 2013

My stack ran without problems for weeks.. and suddenly things don't work anymore coz of an inductive load problem? Doesn't seem likely to me. But I got myself a soldering gun last week, so I can try the varister path.. :-S

If so, maybe I can improve the following Starting Cellar Water Pump Control System @ Tue Mar 26 21:06:46 CET 2013 Running on Java 1.7.0_04 hosted by Mac OS X 10.7.5 Initializing TinkerForge stack.. Aha. Connected @ 20:06:46 because: CONNECT_REASON_REQUEST Done. [1(1/1)] Ouch.. exception @ Tue Mar 26 21:23:25 CET 2013 Switching pump ON @ Tue Mar 26 21:36:47 CET 2013. Time since last: 21:36:47,551. Air: 1010.84,Temp: 12.62,Humid: 71.7,Light: 0.0,Heap: 3.53 MB, [2(1/1)] Ouch.. exception @ Tue Mar 26 21:52:32 CET 2013 Switching pump ON @ Tue Mar 26 22:12:28 CET 2013. Time since last: 00:35:40,947. Air: 1010.84,Temp: 12.43,Humid: 68.4,Light: 0.0,Heap: 2.22 MB, [3(2/2)] Ouch.. exception @ Tue Mar 26 22:21:57 CET 2013 [4(1/2)] Ouch.. exception @ Tue Mar 26 22:37:03 CET 2013 Switching pump ON @ Tue Mar 26 22:49:15 CET 2013. Time since last: 00:36:47,106. Air: 1010.72,Temp: 12.31,Humid: 67.0,Light: 0.0,Heap: 2.04 MB, [5(1/2)] Ouch.. exception @ Tue Mar 26 22:53:15 CET 2013 [6(1/2)] Ouch.. exception @ Tue Mar 26 22:58:22 CET 2013 [7(1/2)] Ouch.. exception @ Tue Mar 26 22:59:35 CET 2013 [8(1/2)] Ouch.. exception @ Tue Mar 26 23:26:47 CET 2013 Switching pump ON @ Tue Mar 26 23:27:23 CET 2013. Time since last: 00:38:08,365. Air: 1010.64,Temp: 12.18,Humid: 67.8,Light: 0.0,Heap: 1.46 MB, [9(1/2)] Ouch.. exception @ Tue Mar 26 23:38:37 CET 2013 Switching pump ON @ Wed Mar 27 00:06:27 CET 2013. Time since last: 00:39:04,013. Air: 1010.62,Temp: 12.12,Humid: 67.1,Light: 0.0,Heap: 1.82 MB, [10(1/2)] Ouch.. exception @ Wed Mar 27 00:40:57 CET 2013 Switching pump ON @ Wed Mar 27 00:46:28 CET 2013. Time since last: 00:40:00,082. Air: 1010.58,Temp: 12.06,Humid: 67.3,Light: 0.0,Heap: 1.68 MB, [11(1/2)] Ouch.. exception @ Wed Mar 27 01:08:24 CET 2013 Switching pump ON @ Wed Mar 27 01:27:32 CET 2013. Time since last: 00:41:04,892. Air: 1010.40,Temp: 11.93,Humid: 67.9,Light: 0.0,Heap: 993.01 KB, Switching pump ON @ Wed Mar 27 02:10:12 CET 2013. Time since last: 00:42:39,914. Air: 1010.13,Temp: 11.87,Humid: 67.9,Light: 0.0,Heap: 3.05 MB, [12(1/2)] Ouch.. exception @ Wed Mar 27 02:47:25 CET 2013 Switching pump ON @ Wed Mar 27 02:52:54 CET 2013. Time since last: 00:42:41,323. Air: 1009.86,Temp: 11.81,Humid: 67.3,Light: 0.0,Heap: 1.93 MB, [13(1/2)] Ouch.. exception @ Wed Mar 27 02:55:19 CET 2013 [14(3/3)] Ouch.. exception @ Wed Mar 27 03:05:07 CET 2013 [15(2/3)] Ouch.. exception @ Wed Mar 27 03:36:57 CET 2013 Switching pump ON @ Wed Mar 27 03:36:58 CET 2013. Time since last: 00:44:04,375. Air: 1009.69,Temp: 11.75,Humid: 67.9,Light: 0.0,Heap: 871.14 KB, [16(4/4)] Ouch.. exception @ Wed Mar 27 03:39:14 CET 2013 [17(1/4)] Ouch.. exception @ Wed Mar 27 03:41:17 CET 2013 Switching pump ON @ Wed Mar 27 04:22:02 CET 2013. Time since last: 00:45:03,828. Air: 1009.44,Temp: 11.68,Humid: 66.7,Light: 0.0,Heap: 817.41 KB, [18(1/4)] Ouch.. exception @ Wed Mar 27 04:40:45 CET 2013 [19(1/4)] Ouch.. exception @ Wed Mar 27 04:56:05 CET 2013 [20(2/4)] Ouch.. exception @ Wed Mar 27 05:03:11 CET 2013 Switching pump ON @ Wed Mar 27 05:08:32 CET 2013. Time since last: 00:46:29,773. Air: 1009.41,Temp: 11.62,Humid: 65.9,Light: 0.0,Heap: 1.77 MB, [21(1/4)] Ouch.. exception @ Wed Mar 27 05:10:51 CET 2013 [22(1/4)] Ouch.. exception @ Wed Mar 27 05:32:41 CET 2013 [23(1/4)] Ouch.. exception @ Wed Mar 27 05:54:30 CET 2013 Switching pump ON @ Wed Mar 27 05:54:32 CET 2013. Time since last: 00:46:00,707. Air: 1009.53,Temp: 11.56,Humid: 67.7,Light: 0.0,Heap: 894.96 KB, [24(1/4)] Ouch.. exception @ Wed Mar 27 06:05:22 CET 2013 Switching pump ON @ Wed Mar 27 06:41:27 CET 2013. Time since last: 00:46:55,102. Air: 1009.57,Temp: 11.56,Humid: 67.3,Light: 0.0,Heap: 2.50 MB, [25(1/4)] Ouch.. exception @ Wed Mar 27 06:46:49 CET 2013 [26(1/4)] Ouch.. exception @ Wed Mar 27 06:47:53 CET 2013 [27(1/4)] Ouch.. exception @ Wed Mar 27 07:03:10 CET 2013 Switching pump ON @ Wed Mar 27 07:27:24 CET 2013. Time since last: 00:45:56,023. Air: 1009.77,Temp: 12.12,Humid: 71.3,Light: 0.0,Heap: 1.70 MB,

Hi, For the first time I had my Dual Relay activate my water pump, and then something happened which resulted in the monoflop behaviour failing miserably. Result: water pump kept running, and running, and running, ... until a poor resident went into cellar and yanked the power cable out of the mains plug. I imagined the monoflop API to be 100% safe.. but it seems it isn't. Does the above scenario mean that the Master Brick connected to the relay actually crashed, preventing it from switching the relay OFF? Is there any API allowing a controlling program to detect stack resets? If I cannot absolutely guarantee that my system never fails to switch the pump off after a reasonable amount of time, then my whole system is dangerously flawed. I cannot have a pump burn out and potentially start a fire... Any ideas on how to solve this problem? Seems to me the TF architecture is missing some auto-reset mechanism (watchdog).

Hi, When a stack has more than one Master, we're dealing with a multi-processor system. Q: do each of the processors then run a full TF "kernel", executing code for their 4 Bricklets only, or does the master Master Brick CPU run the code for all bricklets in the whole stack? I can imagine the answer, but I don't recall any of the docs explaining this architectural point.

I don't like plugging & unplugging bricklets too much, coz those connector pins look so incredibly fragile, but if you give me a hint at how to distribute my bricklets over my two Masters, I'll gladly give it a try. My config is as shown in screenshot.