xsherlock

not sure about that one as it has rtc and stuf. but I successfully used this dumber one

https://www.aliexpress.com/item/32888533624.html on zero + hat

This is V2 latest extension with updated firmware. connection running simple WPA2. The only unusual setup item is that the SSID of network is not broadcast.

The drop period is always the same, is there some kind of watchdog in the brick? 

I have noticed that wifi brick is not reliable. I have a prototype sensor based on the wifi extension (sensor_1) and second one using RPI zero W (sensor_2) running at the same time in the very same location on the uni campus.  Wifi signal is perfect at around -55  The infrastuture is CISCO enterprise AP's

The tinkerforge bricklet will drop from the network occasionaly and will always do that for 3h45m  an then it will recover. Why? What is wrong with it?

On a graph when the response is 1k the sensor is unavailable.

Ok I made a considerable time investment including building a test device with Precise temperature probe to measure how precise is the H2 with 1s sampling and the conclusion is that you need subtract 1 deg C  will make it more or less within .2 of the real temperature

https://www.dropbox.com/s/sd6kd1ieb9dqems/Inked2018-11-13%2013.55.23_LI.jpg?dl=0

BTW attachments still do not work on this forum, please fix it.

@borg We really need to have the API python module updated so we can set samples per second to even lower value then the 1 sps introduced in firmware 2.0.3

While 1 sps made the problem much smaller I see that after 5-10 minutes the sensor will start heating up just slower then it was with 20 samples/s , in my measurements 0.8 to 1.3 deg C.

It is a big problem as the sensor is not reliable as it is now

ok I just loaded new firmware and so far so good.

Now the Hv2 is within 0.05 C  from the PTC that is siting 1cm away from it.

So far so good. will burn it over couple days

Thanks

Maciej

Good it sounds solvable,  as it is a pressing issue for me maybe if we go down to .33 Hz (that is plenty good for the environment monitoring)

I also  see that a cooprocesor was not such a great idea as (for a temp sensor at least) it is a significant heat source as you can see on the IR camera. about 4.5 above ambient that was 25.6 at that moment.

https://www.dropbox.com/s/12wnvxibm1duqod/2018-10-15%2015.36.54.jpg?dl=0

BTW forum Atachments do not work anymore.

---------

on a second thought if that was a self heating issue that would be a problem over time, and it is showing up imediately after I power a sensor device.

Are you planning to use solar charge controller for the battery, or you want to do it exclusively on the TF bricks? How big the panel and battery do you want to use?

I do something similar for the night lights in the kids treehouse right now but will use external charge controler with MPPT tracker to charge the lipo batery pack of around 150Wh.  V/C bricklet just for reporting back to house the status.

Maciej

I just started using the Humidity v2.0 around house and noticed they hive consistently higher temp readout then normal temp bricklets. They were supposed to be more accurate yes?  But I just took out the the PTC bricklet and mounted it next to the Humidity v2 and it gives exact 0.85 deg of diffrence

ptc:26.19  temp Hv2:27.04  diff:0.85

ptc:26.19  temp Hv2:27.04  diff:0.85

ptc:26.19  temp Hv2:27.04  diff:0.85

ptc:26.19  temp Hv2:27.05  diff:0.86

ptc:26.2  temp Hv2:27.05  diff:0.85

And Just to me clear I tested 2 different Humidity V2 units  next to each other and they are exactly the same so that is not a single faulty bricklets.

What is your experience with those?

-----edit

So I tested 2 diffrent sensors  and a PTC concurently and the results are

ptc:20.37  temp Hv2:22.0  temp2 Hv2:21.75  diff:1.63  diff2:1.38

ptc:20.37  temp Hv2:22.01  temp2 Hv2:21.75  diff:1.64  diff2:1.38

ptc:20.37  temp Hv2:22.01  temp2 Hv2:21.74  diff:1.64  diff2:1.37

ptc:20.37  temp Hv2:22.02  temp2 Hv2:21.74  diff:1.65  diff2:1.37

--------------

So now I placed the test setup next to the old classic temp bricklet that shows 

26.0

ptc:26.04  temp Hv2:27.21  temp2 Hv2:26.86  diff:1.17  diff2:0.82

ptc:26.04  temp Hv2:27.21  temp2 Hv2:26.86  diff:1.17  diff2:0.82

ptc:26.04  temp Hv2:27.21  temp2 Hv2:26.86  diff:1.17  diff2:0.82

So it is spot on with the PTC  and the humidity temp redout is 1.2 - 0.8 off  that is way outside the specs

You got the point exactly, I have 2K Euro worth of brick an bricklets and really would appreciate to have a binding update with every new brick released, for sensors I sometimes resort to running a pooling python script on the RPI and  pass the data to openhab with MQTT but that is not the way it should be done

By some fluke of early adopter craze I did ordered a bunch of new briclets to do security system in the shed and should have gone for the old motion sensor and old dualrelay as this one is not supported

Dear,

What is ETA for the support for this bricklet and the new Motion Sensor 2.0

My garden shed just got robbed and the new alarm system (motion sensor bricklets) is on its way already, but to finish it i need openhab suporting the new parts.

TIA

Maciej

On I/O 4 I have a button that shorts The pin to board ground. Detection is done by Tinkerforge OpenHAB binding. I do not understand pull-up sugestion. You want me to add a 1Kohm resistor in the button circuit? The interference does happen if the button is  disconected and the I/O4 is simply conneted to the brick without any pin connected.

For now I have a rough workaround. Since the interference is shorting the pins for about 200ms. I wrote openhab rule that requires 2 sec button press to enable the pump or lights in Pool. But the problem is still there.

hi, I have a simple setup next to the POOL that includes a POE powered Master brick with 4 bricklets.

1)PTC

2)Dual Relay (pool pump, pool lights)

3)Dual Relay (garden light, not used)

4)I/O 4port when I use 2 ports for manual switches for pool pump and pool lights

Now the trick is that when I connect my EV charger to the car (10A) that is on the same phase as pool pump. I/O ports will close for a short time as if the button would be pressed. This will start the pool pump and lights.

I'm guessing there is some interference from the Dual Relay going into the I/O 4port, but how is that possible? From an OH2 log I can see that i/o 4 putton press takes aboout 200ms, Any ideas how to mitigate such a problem?

2018-04-04 22:48:57.874 [itemStateChangedEvent     ] - Pool_in2 changed from OPEN to CLOSED
2018-04-04 22:48:57.881 [itemStateChangedEvent     ] - Pool_in3 changed from OPEN to CLOSED
2018-04-04 22:48:57.901 [itemCommandEvent          ] - Item 'Pool_Relay1_ligths' received command ON
2018-04-04 22:48:57.911 [itemStateChangedEvent     ] - Pool_Relay1_ligths changed from OFF to ON
2018-04-04 22:48:57.923 [itemCommandEvent          ] - Item 'Pool_Relay2_pump' received command ON
2018-04-04 22:48:57.925 [itemStateChangedEvent     ] - Pool_Relay2_pump changed from OFF to ON
2018-04-04 22:48:57.957 [DEBUG] [eclipse.smarthome.model.script.OTHER] - --------- Pool Pump Timer sleep time:7200000
2018-04-04 22:48:58.071 [itemStateChangedEvent     ] - Pool_in2 changed from CLOSED to OPEN
2018-04-04 22:48:58.076 [itemStateChangedEvent     ] - Pool_in3 changed from CLOSED to OPEN

Ok, that is a new one, what is that file exactly?

It looks like dupe of the tinkerforge.cfg  but is out of order and bit different syntax.

Is that a current running config?

Still no solution for that, I think 7 times before I add any new Tinkerforge thingo to my smarthome setup.

I'm now thinking about Virtualization of my OH2 setup to be able to recover it quicker.

As I wrote in the other post reverting the file

/etc/openhab2/services/tinkerforge.cfg

does not help

Also in 2.1 clean instal there is no openhab.cfg any more.

It was annoying in 2.0 but with strict validation in 2.1 if you make an error and it gets cached you have to reinstal OH as it stops to load the tinkerforge binding.

It's a bummer.

If I make a mistake or typo adding new sensor/bricklet to the house setup it stays there forever.

Now with 2.1 setup it gets even more annoying as the validation of all the files is performed. So if it will refuse to load whole file if it finds a syntax error. Reverting to the original file is not erasing it.

The only choice is to always have a backup SD card with old setup in order to recover any mistake you made to Tinkerforge cfg.

That is super annoying

.

In order to learn that I did have to rebuild and OH 2.1 from scratch one evening as I got to the point where OH would not load the Tinkerforge binding config making my house unusable.

I get a very strange openhab 2.1-stable  error.  I tried to add a 0-20mA sensor but it did not work as it should. I edited tinkerforge.cfg. I did a workarounf with python script to get this data.

I removed all 4 lines I added  to thinkerforge.cfg

Now all my tinkerforge devices stopped to work. I get this error.

2017-10-25 15:50:04.294 [ERROR] [org.apache.felix.configadmin        ] - [org.osgi.service.event.EventHandler, org.osgi.service.cm.ManagedService, id=295, bundle=182/mvn:org.openhab.binding/org.openhab.binding.tinkerforge/1.10.0]: Updating property uid: CqV subId: sensor1 of configuration org.openhab.tinkerforge caused a problem: CONFIG: duplicate device config for uid "CqV" and subId "sensor1": fix openhab.cfg
org.osgi.service.cm.ConfigurationException: uid: CqV subId: sensor1 : CONFIG: duplicate device config for uid "CqV" and subId "sensor1": fix openhab.cfg
at org.openhab.binding.tinkerforge.internal.config.ConfigurationHandler.fillupConfig(ConfigurationHandler.java:777)[182:org.openhab.binding.tinkerforge:1.10.0]
at org.openhab.binding.tinkerforge.internal.config.ConfigurationHandler.createOHTFDeviceConfig(ConfigurationHandler.java:397)[182:org.openhab.binding.tinkerforge:1.10.0]
at org.openhab.binding.tinkerforge.internal.config.ConfigurationHandler.createConfig(ConfigurationHandler.java:220)[182:org.openhab.binding.tinkerforge:1.10.0]
at org.openhab.binding.tinkerforge.internal.TinkerforgeBinding.updated(TinkerforgeBinding.java:891)[182:org.openhab.binding.tinkerforge:1.10.0]
at org.apache.felix.cm.impl.helper.ManagedServiceTracker.updated(ManagedServiceTracker.java:189)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(ManagedServiceTracker.java:152)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.helper.ManagedServiceTracker.provideConfiguration(ManagedServiceTracker.java:85)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1772)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:141)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:109)[3:org.apache.felix.configadmin:1.8.12]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_121]

First in 2.x there is no more openhab.cfg so I guess it is referring the tinkerforge.cfg  but any references to CqV are gone from the file.

Where is it cached? Restarting and rebooting does not help. I cant switch a single light in the house now.

Theo any chance you can give me a clue where to look, in order to get rid of this old cached setup.

I have removed all the references of this port b0 in or out from the sitemaps and as you can see it is not there in the tinkerforge.cfg

yesterday upgraded to the latest snapshot of OH2

And I still get this error.

2017-09-10 10:29:45.972 [ERROR] [kerforge.internal.TinkerforgeBinding] - CONFIG existing device is uid wjk subId inb0
2017-09-10 10:29:45.974 [ERROR] [kerforge.internal.TinkerforgeBinding] - CONFIG ignoring duplicate device uid: wjk, subId outb0, genericId {}. Fix your openhab.cfg!

Sorry for not getting back on that one sooner.

The amount of sh*tstorm that hit after moving into half finished smarthome was incredible.I was dealing with OH2 crashes,that resulted in no hot water, flooding, and lack of the electricity from the custom battery subsystems so dimmers were the last thing i was thinking about.

I'm about to test it soon. will report back.

Here it is.

tinkerforge.cfg

ok so I have strange behaviour of the binding. It seems I can't change the setup of one IO16 pinn from in to out. like I simply cant.

I have tripple checked that I have only one reference in the tinkerforge file and it is:

tinkerforge:io16_watering_outb0.uid=wjk
tinkerforge:io16_watering_outb0.subid=outb0
tinkerforge:io16_watering_outb0.type=io_actuator
tinkerforge:io16_watering_outb0.defaultState=false

It was previously an IN port as I genericly set 8 in and 8 out. But I needed an 9th out so I changed it.

But the setting did not change in Reallive and I noticed that in the openhab2 log.

2017-03-06 11:03:28.401 [ERROR] [kerforge.internal.TinkerforgeBinding] - CONFIG existing device is uid wjk subId inb0
2017-03-06 11:03:28.402 [ERROR] [kerforge.internal.TinkerforgeBinding] - CONFIG ignoring duplicate device uid: wjk, subId outb0, genericId {}. Fix your openhab.cfg!

There is no logner a openhab.cfg in the OH2 so that is puzzling.

As a person who have over 1K Euro of TF bricks and bricklets embeded into the smart house. 1 definitely for keeping the old connector. I often have cables running 2 meters from the breakout box with the MasterBrick to the temp or luminosity senso in the wall. Cant imagine to be forced to change those in 3 years timeframe.

I plan to move to Openhab2. Does TF have bindings working in OH2? is there any trick or it should go smooth?

Regards

Maciej

And? how is it going?

12k lumen (140W of LEDs) ilumination  that I motion trigger in the corridor is great when I run into it from the midday sun, but a bit annoying when i stroll to the toilet at 2am.

Maciej