Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by xsherlock

  1. I SOLVED THE PROBLEM! It Must be something with grounding as I added an isolator bricklet for the PTC and it went away in second. I'm still not sure exactly why but the hypothesis is that all the noisy sensors are glued to the pipes with conductive termal paste. And that causes some grounding loop. The PTC5 that was only one clean sensor was a test one, in a loop in the cabinet, It was actually the only one that metal tip of the sensor was not touching the grounded metal pipes. Ordering the remaining 4 isolator now to put it to final test. Anyway, thank you for assi
  2. Hi, I have spent couple more days on testing the setup and rewiring and unfortunately still experience the problems. So I will share all the details and maybe with your external eye you will see something unusual in this one. I have changed a 4 x 0.75mm2 cable to one of the sensors and replaced it with shielded CAT6 ETH cable using 2 twisted pairs as single cable. I have also run that cable in a separate duct pipe on the celling away from all the power cable to the electrical cabinet. I have eliminated the WAGO style connector at the sensor end of the cable, and soldered the
  3. Ok so I rewired the setup and now 2 sensors (Output 1, Output2) are 4 wire (7m extension). 3 named Noel are old setup (2 wire 7m extension). And for comparison I added Poiol skimmer to the graph that is same PTC probe on 2 wire directly to PTC bricklet on the same RPI HAT. As you can see the extension is the problem , adding 2 wires did not improve the noise. Probe directly into the bricklet is super clean. What else could be a problem here? TIA
  4. Yes I you your probe from the shop that is 2 wire. How do I connect a 2 wire PT100 with 4 wires? TIA
  5. Hi ALL, I need to run a longer cable from the PTC bricklet to the the PT100 probe (the one from your shop). I used 2 x1mm^2 sensor cable to extend the 1m that comes with the probe. 7m long. Do you think that can affect the results much? I have some concerns , as that is an important readout I have 2 sensors in exactly the same location, glued together with a thermal glue into one blob attached to the pipe. They are about 1-1.1 degree apart, and output looks a bit noisy. (I read them every 2 seconds) What do you think?
  6. The global source for the system is 100W Meanwell 12V AC PSU with battery backup. For the RPI's I use 60W Meanwell 12V to 5V converter that feeds 5.1V into sensor RPI over HAT power port and one other Openhab RPI over USB-C. I now see that HAT power port is indeed has spec from 5.3V volts up. That could be it. I will power it directly from 12V line to be safe. So far it happend only once.
  7. RPI OS with the snapshot brickd pi@morele-sensor-1:~ $ uname -a Linux morele-sensor-1 5.4.72-v7l+ #1356 SMP Thu Oct 22 13:57:51 BST 2020 armv7l GNU/Linux Nothing could be short as it quite fixed on the test stand, and has not been touched except of the removing the power to RPI that fixed problem. Suprisingly all 4 ptc behaved the same.
  8. Ok so I have it working with the new snapshot version but I had today a very strange case where the RPI booted and all 4 x PTC sensors started returning -246.88 readout all 4 the same readout while the remaining 2 bricklets (VC and Humidity2) on the same large HAT were fine. A reboot not helped but removing power from the HAT fixed it.
  9. ok installing, now, I have a 3 way valve governing 2000l of boiling hot water on that one RPi to manage
  10. so you say that RPI OS can fail any time if I put load on the CPU?
  11. Hi is there any known problem with the following setup as in the title? This is the first time I see that, using the TF parts for years now. But I think it is first time I use RPI4. brickd instals fine. But there is constant stream of errors. brickv connects and sometimes after 15 min will maybe see one bricklet but it will timeout a second later. when run in a foreground the log looks the flowing HELP! sherlock@morele-sensor1:~$ sudo brickd --version 2.4.2 sherlock@morele-sensor1:~$ sherlock@morele-sensor1:~$ sherlock@morele-sensor1:~$ sherlock@morele-sensor1:~$ sudo
  12. meh, this is a no go for me, I need a text file config as often I do auto generate things from a template file for repetitive controllers. (like when I have 10 roms with 4 fancoil heaters each). Would that still be a problem when a user would be very careful not to do any things in PaperUI?
  13. Ok, but in the docs somehow I can find of the basic thing definition example by text , hope that is still possible by the text file, and you are not relying on the PaperUI.
  14. Hi, I see that on a German forum there is nice discussion on the Beta OH2 bindings, I wish we have the same here in English./ What is the status of the binding?, is it any good for production use? Can we have some documentation? I'm just starting a new major automation project that will be OH2 based and wonder if I can start using that binding or I have to rely on the custom Python/MQTT bridges for all of inputs and outputs.
  15. I just rebooted the RPI remotely and that fixes the problem, so it looks like the callback function "expired" I have not checked that unit with Brick Viewer but I'm quite sure it was running fine as that motion sensor does have a temp sensor that was reporting the temps fine all that time when the motion sensor was stuck. Next time I catch that I will try to connect with the BrickViewer at that very moment it fails.
  16. forgot to set notifications on that post.
  17. Hi, I have deployed a network of motion sensors on the campus that have fairly simple construction RPI zero -> MasterBrick -> motion 2.0 bricklet. a python script as a service is running on the units with a callback function to send motion as MQTT message. Sometimes (once every 2 weeks) one of 15 units stops motion detection. The script is still running. And restarting it does not fix the problem. Rebooting a whole sensor with RPI is a solution to a problem. But I have no idea how to detect a problem appeared. TIA
  18. C'mon translate that to english, I'm waiting for those proper binding for months.
  19. Hi, I need to read 2 x NTC 10K termistors values, Can that be done with any tinkerforge brick? Maciej
  20. 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
  21. 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?
  22. 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.
  23. 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.
  24. @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
  25. 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
  • Create New...