xsherlock

OMG, I designed all the dimmers in the house to accept 0-10V input for the dimmers and just noticed that Analog Out 2.0 does not have a binding for the OpenHab. Theo will you add the support for it, please! Maciej

I have made more tests and it looks that over Wifi iy will work reliably but over POE it will always fail after couple switches. I tried a super save setup with industrial quad relay bricklet switching 12V for the coil of a 2 contact 230V relay (that was cutting both neutral and phase) and that also has time out problems. As a last resort I ordered a new 1.1 POE to test and will also try to disable power over ethernet and use stepdown power supply while stll use cabled connection, but it looks as the POE extension design is flawed in some way. ------------- POE extension 1.0 with external power is a no go... same hangups. A package arrived and instead POE 1.1 I just got new plain Ethernet extension 1.1. Tested it to work with Quad Industrial relay and dual contact external relay. Cant kill that setup and I loose no pings on the way. Will update when I finaly get new POE extension. ------------------ Just got POE 1.1 and it is working flawless switching the relays under load. So the issue was POE 1.0 having a bug.

Just today I got some bogus values, not absurd like previously, but for sure false. The 3 PTC probes are inside the 1.2m3 of hot water tank that did not cool down magically by 6degrees for half an hour. ------ Ohh, that was easy, when I switch light in the basement and get this result, so that is noise from AC wire I guess.

The new setup was working flawlessly all morning when I had no devices connected to the relays. The relay board is a 5V one and it powered from the power out on the IO16. The very moment I did connect a 230V device ( 3 way heating valve max 10W) the masterbrick started crashing again exactly like it was with dual relay. Further testing is required to see if that IS something related to POE power or there is no isolation somewhere and there is a clash between the POE in and Relay board but I was hoping that should not be a problem with IO16 ----- Ok Now I'm sure that connecting a 230V Phase to the relay board and switching that relay will cause Masterbrick to hang. It is enough to connect a single relay to the phase and common neutral to the switched device and it will cause problems. The switched phase was the same that powers POE switch I tested that on 4 separate configurations and 2 different MasterBricks Masterbrick(1) with POE ext-io16-5v Relay board powered from the io16. Masterbrick(1) with POE ext- dual relay Masterbrick(1) with wifi ext, USB power PS - dual relay Masterbrick(2) with POE ext - io16- 12Vrelay board with separate 12V PS for relays. The last config will also crash but in slightly different manner. It will stop pinging back for about 7 seconds after first 2-3 relay switches. And then it will recover after a period of non responsiveness. That is the 2nd picture. I run out of ideas, what am I doing wrong, and why it does not work. Is that my cabling? or some earthing problem?

I noticed that on my other MasterBrick with 8 relays on the IO16 bricklet I could not crash the stack no matter how much I would hammer the relays with switch commands. So I spent whole day rebuilding the panel in the boiler room rewiring it to the IO16 and external relay boards. As I now suspect that the issue is related to the dual relay bricklet (I only have one so cant replace it) I will have a conclusion tomorrow.

I just swapped Ethernet POE extension for the wifi Extentension. No other changes. pi@rpi-openhab ~ $ ping 172.16.10.20 -s 1400 PING 172.16.10.20 (172.16.10.20) 1400(1428) bytes of data. 1408 bytes from 172.16.10.20: icmp_req=1 ttl=255 time=5.89 ms 1408 bytes from 172.16.10.20: icmp_req=2 ttl=255 time=5.71 ms 1408 bytes from 172.16.10.20: icmp_req=3 ttl=255 time=5.71 ms ^C --- 172.16.10.20 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 5.711/5.772/5.890/0.120 ms As you can see it pings back nicely for all sizes. But the stack will still crash on numerous dual relay actions. If I use REST to switch it after 3rd 4th it will kill the stack and it stops pinging back!!!! So the bug is not isolated to the POE extension

Yep, I was just pinging the stacks from the Windows machine. Same problem That is some kind of glitch, that could be or not causing problems with openhab. I can imagine that if some sensor updates are to arrive at the same time the relay is fired that could be packed into larger TCP packet that does not pass and hence the timeout.

If the Masterbrick is connected to the host over USB then it will ping back fine . I have one connected to the Redbrick (in my case 172.16.2.156). Only those stacks that are made of the MasterBrick and Ethernet Extension POE fail to ping back. I have connected 2nd stack with new out of the box MasterB and EthernetEXT POE and it experience the very same problem. It is 100% reproducible and the very first packet >128 bytes does not pass it has little to do with waiting. I did upgraded to 1.8.2 before today tests. I have no EthernetEXT without POE but will try to set the switch not to provide power and power the stack over USB. This is the test to do C:\Users\sherlock>ping 172.16.10.10 -l 128 Pinging 172.16.10.10 with 128 bytes of data: Reply from 172.16.10.10: bytes=128 - MISCOMPARE at offset 119 - time=220ms TTL=128 Reply from 172.16.10.10: bytes=128 - MISCOMPARE at offset 119 - time=169ms TTL=128 Reply from 172.16.10.10: bytes=128 - MISCOMPARE at offset 119 - time=217ms TTL=128 Ping statistics for 172.16.10.10: Packets: Sent = 3, Received = 3, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 169ms, Maximum = 220ms, Average = 202ms C:\Users\sherlock>ping 172.16.2.156 -l 128 Pinging 172.16.2.156 with 128 bytes of data: Reply from 172.16.2.156: bytes=128 time=90ms TTL=64 Reply from 172.16.2.156: bytes=128 time=10ms TTL=64 Ping statistics for 172.16.2.156: Packets: Sent = 2, Received = 2, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 10ms, Maximum = 90ms, Average = 50ms

What other way do you want me to stress test this stack. I can do that. --------- I just made stack crash in a simple way with brickv. I did flop the dual relay couple of times and it stopped pinging back and imediately openhab throwed the timeouts. ------ Some more findings. Reducing the stack to single MasterBrick and Ehternet POE extension and a single DualRelay bricklet will still make it crash. The stack stops pinging and then sometimes it recovers and some times it does not and requires a reboot. I can flood ping a stack with small packet at 10hz and it is fine but it will not ping back on from anything larger then 128 bytes !!!!! This could be the source of the problem! pi@rpi-openhab ~ $ ping 172.16.10.20 -s 120 PING 172.16.10.20 (172.16.10.20) 120(148) bytes of data. 128 bytes from 172.16.10.20: icmp_req=1 ttl=128 time=0.354 ms wrong data byte #119 should be 0x77 but was 0x74 #8 8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 #40 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40 41 42 43 44 45 46 47 #72 48 49 4a 4b 4c 4d 4e 4f 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 60 61 62 63 64 65 66 67 #104 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 74 ^C --- 172.16.10.20 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.354/0.354/0.354/0.000 ms pi@rpi-openhab ~ $

I have got a case when the openhab reported a timeout and the stack was still pinging back but I was unable to connect with brickv. Also rebooting the stack, does not always make the openhab to recover. Sometimes I need to restart openhab as well. All my sensors are at 1000ms callback. is that stressing the openhab? One more think is that for the reason not to the get bogus readout every now and then the temp sensors have tinkerforge:temperature.slowI2C=True set. But not the PTC sensors or Humidity. Can that be a mismatch?

Hmm, that is not good, maybe Theo would look into it as I guess that came with the 1.8 version of openhab and he is the developer of the bindings. Before I decided to do the whole Home Automation on TF bricks, I was hammering a simple setup of 1 Temp bricklet and 1 dual relay for over 2 moths and never seen it time-out this way. That was running 1.7 with some snapshot 1.8 bindings that I needed for one feature. The only other thing is that was a brick connected to the REDbrick and not to the Ethernet Extension. But I see you have the same problem on the direct connection from RPI so it could be not the Ethernet Extension that was my best suspect. I will update to 1.8.2 as it came out today. And try to simplify my setup to isolate the bug.

Hi, It looks I hit some bug. My setup is RPI running openhab 1.8.0 and couple of masterbrick around house for the home automation. All master bricks have Ethernet extension (old one). All powered by POE. The particular one is a stack of 2xMasterBrick and Ethernet with 7 bricklets 3 x PTC 2 x Temp 1 x Humidity 1 x DualRelay I switch the relay 3-4 times in 2 sec intervals and the whole stack becomes unresponsive. Stops pinging back and requires power cycle. The logs reads 2016-03-23 22:54:58.434 [ERROR] [.t.i.m.impl.PTCTemperatureImpl] - Tinkerforge Error: Tinkerforge timeout occurred : Did not receive response in time for function ID 1 2016-03-23 22:55:00.936 [ERROR] [.t.i.m.i.MBrickletHumidityImpl] - Tinkerforge Error: Tinkerforge timeout occurred : Did not receive response in time for function ID 1 2016-03-23 22:55:03.437 [ERROR] [t.i.m.i.MDualRelayBrickletImpl] - Tinkerforge Error: Tinkerforge timeout occurred : Did not receive response in time for function ID 2 2016-03-23 22:55:05.946 [ERROR] [i.m.i.MBrickletTemperatureImpl] - Tinkerforge Error: Tinkerforge timeout occurred : Did not receive response in time for function ID 1 2016-03-23 22:55:08.452 [ERROR] [.t.i.m.impl.PTCTemperatureImpl] - Tinkerforge Error: Tinkerforge timeout occurred : Did not receive response in time for function ID 1 2016-03-23 22:55:10.958 [ERROR] [t.i.m.i.MDualRelayBrickletImpl] - Tinkerforge Error: Tinkerforge timeout occurred : Did not receive response in time for function ID 2 2016-03-23 22:55:13.472 [ERROR] [i.m.i.MBrickletTemperatureImpl] - Tinkerforge Error: Tinkerforge timeout occurred : Did not receive response in time for function ID 1 2016-03-23 22:55:15.974 [ERROR] [.t.i.m.impl.PTCTemperatureImpl] - Tinkerforge Error: Tinkerforge timeout occurred : Did not receive response in time for function ID 1 Am I doing something wrong?

One more thing I noticed with PTC and normal sensors is that they are sensitive to the fact if 230V power cable is any nearby. Sometimes this introduces a jitter in the readout. I would keep at least 10 cm space

After swapping cables around my PTC sensor surprisingly got OK and gets me reasonable values for the last week. You can not rely on the is_sensor_connected because in my case it was also showing that the sensor is connected when the readouts were bogus.

I did review my install and swapped the cables on the offending sensor. Does it makes any difference if the red is B and C is white? It shouldn't I think. Instantly the sensor went to normal temp and is staying there for now.

ok that sensor is sighting in unheated room on my with max temp of 6 deg C. I hace second one next to it 5cm away that is fine. Results read with openhab and with brickv and they are the same. Maciej

Looks clean to me. 2016-01-18 23:57:27.060 [ERROR] [.t.internal.TinkerforgeBinding] - COMMAND no tinkerforge device found for command for item uid: kDz subId: relay1 2016-01-18 23:57:27.915 [ERROR] [.t.internal.TinkerforgeBinding] - COMMAND no tinkerforge device found for command for item uid: kDz subId: relay2 2016-01-18 23:57:28.965 [ERROR] [.t.internal.TinkerforgeBinding] - COMMAND no tinkerforge device found for command for item uid: kDz subId: relay1 2016-01-18 23:57:29.862 [ERROR] [.t.internal.TinkerforgeBinding] - COMMAND no tinkerforge device found for command for item uid: kDz subId: relay2 2016-01-19 00:00:10.737 [iNFO ] [penhab.io.rest.RESTApplication] - Stopped REST API 2016-01-19 00:00:29.513 [iNFO ] [.o.core.internal.CoreActivator] - openHAB runtime has been started (v1.8.0). 2016-01-19 00:00:34.655 [iNFO ] [o.o.i.s.i.DiscoveryServiceImpl] - mDNS service has been started 2016-01-19 00:00:35.146 [iNFO ] [o.o.i.s.i.DiscoveryServiceImpl] - Service Discovery initialization completed. 2016-01-19 00:00:35.171 [iNFO ] [.io.transport.mqtt.MqttService] - MQTT Service initialization completed. 2016-01-19 00:00:35.173 [iNFO ] [o.i.t.m.i.MqttBrokerConnection] - Starting MQTT broker connection 'mymosquitto' 2016-01-19 00:00:43.455 [iNFO ] [c.internal.ModelRepositoryImpl] - Loading model 'default.sitemap' 2016-01-19 00:00:44.323 [iNFO ] [c.internal.ModelRepositoryImpl] - Loading model 'mysql.persist' 2016-01-19 00:00:44.509 [iNFO ] [c.internal.ModelRepositoryImpl] - Loading model 'default.items' 2016-01-19 00:00:45.242 [iNFO ] [penhab.io.rest.RESTApplication] - Started REST API at /rest 2016-01-19 00:00:50.530 [iNFO ] [.o.u.w.i.servlet.WebAppServlet] - Started Classic UI at /classicui/openhab.app 2016-01-19 00:00:55.011 [iNFO ] [c.internal.ModelRepositoryImpl] - Loading model 'default.rules' 2016-01-19 00:00:56.368 [iNFO ] [.service.AbstractActiveService] - HTTP Refresh Service has been started 2016-01-19 00:00:56.971 [iNFO ] [.service.AbstractActiveService] - Tinkerforge Refresh Service has been started 2016-01-19 00:00:56.972 [iNFO ] [.service.AbstractActiveService] - NTP Refresh Service has been started 2016-01-19 00:01:35.830 [iNFO ] [c.internal.ModelRepositoryImpl] - Refreshing model 'default.items' 2016-01-19 00:04:36.069 [iNFO ] [c.internal.ModelRepositoryImpl] - Refreshing model 'default.sitemap' I hooked up a PTC probe and unfortunately it also looks that it does return bogus temp values. Can it take tinkerforge:temperature.slowI2C=True config parameter?

It is still there, I copied all the 1.7 configs and just checked it again.

Theo, Is the Tinkerforge addon distributed with Openhab 1.8.0 the same you gave me for download? I did upgrade to 1.8, by uninstaling and doing a proper apt-get 1.8, then overwritten the configs with my tried and working 1.7 setup and I get the negative -100 values again. Twice in the last 3 days. And now it is even worse as the redbrick I have sensor attached stops responding at all. hanging up the readout until I reboot.

OK, that is smart. I still however have a bit of the problem setting up a second IO16, First is configured as in the examples tinkerforge:io16.uid=w1j tinkerforge:io16.type=bricklet_io16 tinkerforge:io16.debouncePeriod=100 tinkerforge:io16ina0.uid=w1j tinkerforge:io16ina0.subid=ina0 tinkerforge:io16ina0.type=iosensor How do I add the second one? Like that? tinkerforge:io16_second.uid=xxx tinkerforge:io16_second.type=bricklet_io16 tinkerforge:io16_second.debouncePeriod=100 tinkerforge:io16ina0_second.uid=xxx tinkerforge:io16ina0_second.subid=ina0 tinkerforge:io16ina0_second.type=iosensor

Thanks for the hint. I did check this solution, but unfortunately it come with hell lot of compromises. First the switch is no longer a switch in a gui but a set of two buttons. Second the bulb icon is still reversed Third the group master switch works on the original state and not mapped one. -switches the relays on when master_off is pressed So it is a dead end. Maciej

+1 on this. I love the OLED boards design. Read the API and it looks for me they are nightmare to work with. Variable font size support as well would be welcome. And if you could please share the source code of the servo example from the video. Maciej

My openhab skills still wait to get improved in order to be sure if I can make it with the mapping. In the meantime I ordered other relay board that has jumpers to do set the low/high logic. Unfortunately it is 12V so it will require additional power. It looks that all 5v 8x relay boards on the internet are the clones of the same design and take low signal to energize the relay. For some reason.

Hi, I'm using io16 to drive inexpensive relay board to do light switching in home. I'd love to see a way to reverse the logic of the switch in openhab. When the output is defined as true in the example. tinkerforge:io16outb0.defaultState=true The relay is disengaged, does not take power, but the switch in the site map is ON. I'd love see it OFF in that state at that moment Of course it is possible to start the output in the defaultstate=false. But that implies some annoyances that are hard to accept. First the setup starts with applying about 0.4W of power per relay. that will end up with unnessesary 20-30W residual load on the whole house during the day when the light are off. Second in case openhab crashes/reboots i end up with all ligths on !! all the time. So the most elegant way would be to revese the logic on the sitemap only, is there a way to do it? regards Maciej

Ok that is brutally simple. But can you tell me how openhab knows that particular "XYZ" bricklet is behind given IP address. Does it use multicast to communicate or it is using pooling on the setup phase to determine that? Maciej