JavaLaurence

Currently IPConnection lets you connect to one fixed IP address. It would be nice if you could give a range of IP addresses to IPConnection, so that it connects to the first address that accepts a connection and talks Protocol 2.0. Why? Because on most peoples' routers, DHCP will just hand out IP addresses on a first-come, first-served basis. So every time a router resets for whatever reason, a stack can receive a different IP address compared to last time... which doesn't play well with the current static address scheme. I know that some routers can be configured to bind fixed IP addresses to MAC addresses, but I'm in luck: mine does not have that feature. So if IPConnection could hunt for the first IP address that has a stack behind it, that would be very helpful.

The docs for the bricklet state: * Temperature range from -40°C to 125°C * Output in 0.1°C steps (12bit resolution) So that's a range of 165 degrees, subdivided in tenths.. that's 1650 possible values. 12 bits give you the integer range 0..4095. The 1650 possible temperature range comfortably fits in 11 bits (0..2047), but not in 10 bits (0..1023). Does that mean we're talking about 1 extra noise bit (the LSB), or do the so-called analog values arrive offset by some base value for -40 degrees? Secondly, if "Output in 0.1°C steps", then why does Brickv show my temperature values toggling noise-like between 12.50 and 12.56 degrees, with never a value in-between, as one would expect? I see the same phenomenon with my Distance IR values.. they toggle between two values that are several units of accuracy apart, not just the single unit. It's as if the claimed accuracy is wrong, but I'm sure that's not the explanation. Just curious.

Cool... sounds like I need to grab a new JAR :-) :-)

Yes, even with my extremely limited electronics knowledge, I thought of powering the LCD separately too. I could sever the 5V and ground lines (pin 1 & 2) of the bricklet cable, and provide those lines from a little supply next to LCD. A hack in the purest sense of the word ;-) But I'll try lengthening the cable first. Ya never know..

getDistance() just keeps "working", like the Duracell bunny ;-) I'll give you the code so that you can follow the logic, but first, dinner calls... back later. L.

Thanks for the replies. I appreciate the modular nature of the product range, but adding a whole new stack (you forgot new power supply, there's no USB floating in our kitchen), just to bridge a few feet seems like lots of $$$ for very little. I read that I2C wiring can carry signals over a much longer range, so can you tell me which aspect of your cable design is the most voltage-drop dependent? Would adding 2m of wiring between the connectors be a guaranteed waste of time, or do you think there's a chance it could work (just like my stack apparently having no problem with switching on/off my water pump - an inductive load :-) Thx again. L.

Short "post-mortem" comment for people who are interested in this thread. The final conclusion was that the Step Down was not broken at all. It was a Master Brick problem. I bought two Master Bricks, and the dead rail problem only occurs with one of the Masters. If both are in the stack, the stack also doesn't get any power.

Got a couple of questions re: cables. Is TF planning to offer a female-female connector so that two cables can be hooked together to obtain a longer cable? Is TF planning to offer a cable-making kit? If not, can we be pointed in the right direction (links) so that users can make non-standard lengths? TF sells the connectors, but how does one attach these to a suitable cable? Thx. Laurence PS. Trying to install my LCD in kitchen with stack in cellar. Unfortunately, I need 3.5m to reach. :-S

Photron: you write "Finally, your getDistance() won't return you a value in case IPconnection.sendRequest() fails the way you've described, because without a request being send there won't be any response and Device.sendRequest() will raise a TimeoutException." .. but I don't see any TimeoutException, and getDistance() does return happily. That's the point. getDistance() does return .. with a broken connection.

The LCD is not yet installed.. mainly because I haven't figured out how to embed it in some compact frame giving non-technical users (my girlfriend..) decent, fingertip-sized buttons. The 4 buttons on the LCD are ridiculously small, and at 90 degrees from what you would expect, and I'm not a great DIY person, so still struggling on that one. But I also virtualized the LCD, and that version is installed: it is running on my Mac as I write. And I've got the emulated LCD output constantly saved as a file, and that file is embedded in a web page served by my Mac... so I can follow the system's basic status from anywhere in the house, and outside. But my intention is still to also have the physical LCD20x4 in the kitchen, which will probably force me to make my own 3-4m cable. Whether the signals will reliably carry this far, time will tell. The Distance IR works, but I think I need to reposition it to be (a lot) further from the water surface. I bought the 1.5m sensor, and currently I've got it sensing the surface in the range 9cm-15cm, and that is giving me issues. BTW, I also virtualized the Distance IR and Dual Relay bricklets.. and developed the control software before I even had the physical components

The Wifi module needed to be much closer to my AP than initially thought. With the AP in the living room on the ground floor, and the module in the cellar, there was no connectivity. I had to move the AP to within 3m of the module. Between the two there's a brick wall + cellar ceiling. Even this way, the received signal is poor. And that's with the big antenna. So yes, you could say I had Wifi issues. :-S Another thing that happened last night is this: Starting Cellar Water Pump Control System @ Wed Feb 20 20:55:46 CET 2013 Switching pump ON @ Wed Feb 20 21:46:23 CET 2013. Duration: 00:00:24 Switching pump ON @ Wed Feb 20 22:39:59 CET 2013. Duration: 00:00:26 Switching pump ON @ Wed Feb 20 23:35:33 CET 2013. Duration: 00:00:17 Switching pump ON @ Thu Feb 21 00:15:16 CET 2013. Duration: 00:00:17 Switching pump ON @ Thu Feb 21 00:57:13 CET 2013. Duration: 00:00:17 Switching pump ON @ Thu Feb 21 01:38:26 CET 2013. Duration: 00:00:17 Switching pump ON @ Thu Feb 21 02:24:57 CET 2013. Duration: 00:00:23 Switching pump ON @ Thu Feb 21 02:25:25 CET 2013. Duration: 00:00:01 Switching pump ON @ Thu Feb 21 03:18:48 CET 2013. Duration: 00:00:23 Switching pump ON @ Thu Feb 21 04:11:28 CET 2013. Duration: 00:00:36 Switching pump ON @ Thu Feb 21 05:14:14 CET 2013. Duration: 01:12:41 Switching pump ON @ Thu Feb 21 06:30:07 CET 2013. Duration: 00:00:18 So I need to enhance my logic with a timer override to switch off after a certain period (40 seconds, for example). No idea why the sensor didn't trigger a switching off.... maybe a spider installed itself right in front ? No idea.

A suggestion: the bindings .zip contains the version in its filename, but it would also help if the TinkerForge.jar did the same. In Java land, it is common practice to have library JARs with versioned filenames.

Hi TF team, Today I briefly disconnected the power to my stack, and discovered that my program spat out several stack traces without actually crashing my program. java.net.SocketException: Host is down at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109) at java.net.SocketOutputStream.write(SocketOutputStream.java:141) at com.tinkerforge.IPConnection.write(IPConnection.java:762) at com.tinkerforge.Device.sendRequestExpectResponse(Device.java:192) at com.tinkerforge.BrickletDistanceIR.getDistance(BrickletDistanceIR.java:224) at com.softwarepearls.lego.hardware.tinkerforge.impl.tf.input.TFDistanceIR.getDistance(TFDistanceIR.java:89) at com.softwarepearls.apps.hardware.tinkerforge.waterpump.CellarWaterPumpController.dealWithWaterLevelAndPump(CellarWaterPumpController.java:203) at com.softwarepearls.apps.hardware.tinkerforge.waterpump.CellarWaterPumpController.controlLogic(CellarWaterPumpController.java:191) at com.softwarepearls.apps.hardware.tinkerforge.waterpump.CellarWaterPumpController.start(CellarWaterPumpController.java:174) at com.softwarepearls.apps.hardware.tinkerforge.waterpump.CellarWaterPumpController.main(CellarWaterPumpController.java:370) Looking at how IPConnection is implemented, I can see lots of places where you code things like this: try { ...; } catch(java.io.IOException e) { e.printStackTrace(); } This is not very nice, and ignores several Java best practices. Especially since the TinkerForge API has a NotConnectedException, doing the above doesn't make sense. My code is trying to catch the NotConnectedException, but instead it never arrives, and my System.out fills up with stack traces... A much cleaner approach would be to code most of your try-catches as follows: try { ...; } catch(java.io.IOException e) { throw new NotConnectedException(e); // retain root cause exception! } That way, the top-level application can decide to do what it wants with the exception (and the console stays clean). In general, you also want to avoid all e.printStackTrace(); statements. Library components should never do this, as the application logic has no way of reacting to, nor suppressing, such events. Finally, in the above scenario I'm doing a getDistance() on my DistanceIR ... but it happily returns some value (what value? the connection is down!), without throwing an exception. In my book, that's broken behavior. HTH Laurence

Thank you very much for the link. The more I deal with TinkerForge, the more I'm learning German (never learned it at school I'm afraid..). :-)

Anyone hooked up a pluviometer to a stack? Even if not, does anyone have any ideas how to do this? Particularly a digital pluviometer.. Thx.

Sure, in the docs for the Distance IR, the following method public void setSamplingPoint(short position, int distance) could be documented clearer by adding a graph.

Thanks for picture. Would be nice if there was some programmatic way of determining this though. Guess there isn't..

Thanks. My stack currently consists of Step-Down, Master, Wifi Extension, Distance IR, Dual Relay and Humidity. Is the 0.8 Watt figure possible for this configuration? As a software person, I'm not used to dealing with electrical units like this..

My stack is powered by a Step-Down Bricklet, and brickv indicates that Stack Voltage is 9.5V and Stack Current is 160mA. School physics taught me that Watts = Volts x Amperes. Although a figure of 9.5V is given for "Stack Voltage", I'm assuming that actually the stack is run on 5V, not 9.5V. So does this mean that my stack only consumes 0.8 Watt? Seems like peanuts.. or is my math & physics way off ? Maybe it would be cool to let Brickv display stack power consumption too...

Delighted to add that the system is now physically installed in my cellar, and works perfectly (so far). I didn't add any "inductive load problem" protection (mainly because I don't even have a soldering gun or components to add..), and luckily the stack doesn't suffer any issues. Took me a whole afternoon drilling walls and wood and generally hooking things up.. but worth it ! :-) I haven't installed the physical LCD in the kitchen yet (I think my 2.0m TF cable won't even reach :-( ).. but I'm attaching a screenshot of my virtual LCD20x4 which is showing the status of my solution. If you develop in Java, and you're interested in my code.. just give me a sign.

I think the current online API documentation is really good, but there's one change that would improve it even further: the inclusion of pictures. Often certain concepts remain opaque or maybe ambiguous when expressed in pure text.. while adding a simple picture could clarify things. HTH

When I ordered the Distance IR briclet, I specified the "long distance" sensor from the available options: GP2Y0A41: 4cm - 30cm (1.57” - 11.81”) GP2Y0A21: 10cm - 80cm (3.94” - 31.50”) GP2Y0A02: 20cm - 150cm (7.87” - 59.06”) How can I confirm that the shipped sensor is the correct one? I'm getting readings that look more like those produced by a A41 instead of A02. Can brickv tell me which sensor I've got? Thx.

When one clicks Updates/Flashing, Brickv seems to take a long time (10+ seconds) before it can report on any possible updates that are available. This mechanism could be speeded up a lot by just connecting to your site, grabbing a minuscule little file containing firmware/plugin names, versions and MD5 hashes (or similar). And then comparing with the local situation. Only if the user wants to carry an actual update would you then go and download actual binary files. HTH.

Hi, I'd like to help, but then you will have to post in English.. I have quite a bit of Java experience. HTH.

Bit slow this morning.. isn't this like the Temperature bricklet then?