Jump to content

xsherlock

Members
  • Posts

    96
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

xsherlock's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. Hi, I just started with the e-paper and I run into behaviour of it that I cant explain, maybe you can help me. (gray model) I works perfectly predictable in normal update mode (7s one) but when set to the delta mode it seems like the color constants are no longer valid and fill display white does fill it with black instead. ep = BrickletEPaper296x128(epaper_uid, ipcon) ep.set_display_type(1) ep.set_update_mode(0) ep.fill_display(ep.COLOR_WHITE) ep.draw_text(16, 48, ep.FONT_24X32, ep.COLOR_BLACK, ep.ORIENTATION_HORIZONTAL,clock.strftime("%H:%M:%S")) ep.draw() time.sleep(10) ep.set_update_mode(2) ep.fill_display(ep.COLOR_WHITE) clock = datetime.datetime.now() ep.draw_text(16, 48, ep.FONT_24X32, ep.COLOR_BLACK, ep.ORIENTATION_HORIZONTAL,clock.strftime("%H:%M:%S")) ep.draw() my logic is that I before calling the second draw I fill the buffer with white, draw next clock and then call draw to dispay and the text should update. Unfortuantely the above causes the screen to go all black why?
  2. 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 assisting me in solving it.
  3. 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 sensor cable to the extension cables. That did not have much of the influence on the output jitter. Here is a main view on my Tinkerforge automation cabinet. There are 2 RPI's with LARGE HATS that are my sensor hubs gathering all the data from bricklets with a python script service They are powered with 13.8V from the MeanWell PS that has battery backup. There are also 2 RPI's on the top in enclosures, that have OpenHab and Influx/Grafana completeing the setup. You can see in bottom left, a PTC5 proble connected the RPI 1 - that one is perfectly stable. Connected here for reference. Here are some of the connection closeups on the sensor cables that are the original one and the replaced cable for PTC6 All tightend well. The PTC 4 and 6 are set in the sooftware to the ptc6.set_wire_mode(4) On the sensor side. There is just a junction box with now soldered cables, as I removed the WAGO connectors already I focused my repair eforts on the pool output sensors PTC4 and PTC6 as those feed data to the 0-10V cotroled 3way Valve for precise temp control. The PTC1-3 in the NOEL heat storage tank are still extended with just 2 wire 0.75mm2 cable. So for the last day I see the following results. As you can see the PTC5 that is on 2 wires and directly to the brick is rock SOLID stable. One of the NOEL 2 wire long cable sensor is much better then other2 (Why?) Both PTC4 and 6 have huge problems with jitter and some additional spikes, that seem to corelate to the power use of the whole setup (that is measured by the isolated VC 2.0 Bricklet, that very much can also have a problem of accuracy) Basically that is a closed underground technical cavern and such a sudden changes in temp are completely impossible. No other electrical devices (like heatpums or pool pumps are switched on at that time) I'm running out of ideas what can I try to fix that. My last resort would be tring to add isolator bricklets to the PTC (makes any sense)? Adding RPI in the juncion box to measure The PTCs on a short cable (major rebuild). TIA for any sugestions Maciej
  4. 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
  5. Yes I you your probe from the shop that is 2 wire. How do I connect a 2 wire PT100 with 4 wires? TIA
  6. 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?
  7. 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.
  8. 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.
  9. 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.
  10. ok installing, now, I have a 3 way valve governing 2000l of boiling hot water on that one RPi to manage
  11. so you say that RPI OS can fail any time if I put load on the CPU?
  12. 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 brickd --debug brick.log 2020-11-19 18:07:15.686866 <I> <main_linux.c:367> Brick Daemon 2.4.2 started (pid: 2095, daemonized: 0) 2020-11-19 18:07:15.687000 <W> <log.c:115> Unexpected char 'b' in debug filter 'brick.log' at index 0 2020-11-19 18:07:15.693281 <I> <bricklet.c:270> Found supported HAT product_id 0x084e in device tree, using default HAT Brick config 2020-11-19 18:07:15.693374 <I> <bricklet.c:311> Found Bricklet port A (spidev: /dev/spidev0.0, driver: gpio, name: gpio23, num: 23) 2020-11-19 18:07:15.693463 <I> <bricklet_stack_linux.c:117> Using BCM2835 backend for Bricklets (Raspberry Pi detected) 2020-11-19 18:07:15.697455 <I> <bricklet.c:311> Found Bricklet port B (spidev: /dev/spidev0.0, driver: gpio, name: gpio22, num: 22) 2020-11-19 18:07:15.697624 <I> <bricklet.c:311> Found Bricklet port C (spidev: /dev/spidev0.0, driver: gpio, name: gpio25, num: 25) 2020-11-19 18:07:15.697772 <I> <bricklet.c:311> Found Bricklet port D (spidev: /dev/spidev0.0, driver: gpio, name: gpio26, num: 26) 2020-11-19 18:07:15.697905 <I> <bricklet.c:311> Found Bricklet port E (spidev: /dev/spidev0.0, driver: gpio, name: gpio27, num: 27) 2020-11-19 18:07:15.698071 <I> <bricklet.c:311> Found Bricklet port F (spidev: /dev/spidev0.0, driver: gpio, name: gpio24, num: 24) 2020-11-19 18:07:15.698211 <I> <bricklet.c:311> Found Bricklet port G (spidev: /dev/spidev0.0, driver: gpio, name: gpio7, num: 7) 2020-11-19 18:07:15.698361 <I> <bricklet.c:311> Found Bricklet port H (spidev: /dev/spidev0.0, driver: gpio, name: gpio6, num: 6) 2020-11-19 18:07:15.698504 <I> <bricklet.c:311> Found Bricklet port I (spidev: /dev/spidev0.0, driver: gpio, name: gpio5, num: 5) 2020-11-19 18:07:15.700835 <E> <bricklet_stack.c:396> Frame error (port: I, count: 1) 2020-11-19 18:07:15.705105 <E> <bricklet_stack.c:396> Frame error (port: I, count: 3) 2020-11-19 18:07:15.711404 <E> <bricklet_stack.c:396> Frame error (port: I, count: 4) 2020-11-19 18:07:15.717774 <E> <bricklet_stack.c:396> Frame error (port: I, count: 7) 2020-11-19 18:07:15.724422 <E> <bricklet_stack.c:478> Message checksum error (port: I, count: 1) 2020-11-19 18:07:15.726721 <E> <bricklet_stack.c:478> Message checksum error (port: I, count: 2) 2020-11-19 18:07:15.733134 <E> <bricklet_stack.c:396> Frame error (port: I, count: 10) 2020-11-19 18:07:15.739503 <E> <bricklet_stack.c:396> Frame error (port: I, count: 13) 2020-11-19 18:07:15.745844 <E> <bricklet_stack.c:396> Frame error (port: I, count: 14) 2020-11-19 18:07:15.750116 <E> <bricklet_stack.c:396> Frame error (port: I, count: 15) 2020-11-19 18:07:15.758759 <E> <bricklet_stack.c:478> Message checksum error (port: I, count: 3) 2020-11-19 18:07:15.763057 <E> <bricklet_stack.c:396> Frame error (port: I, count: 19) 2020-11-19 18:07:15.771756 <E> <bricklet_stack.c:478> Message checksum error (port: I, count: 4) 2020-11-19 18:07:15.773989 <E> <bricklet_stack.c:478> Message checksum error (port: I, count: 5) 2020-11-19 18:07:15.776196 <E> <bricklet_stack.c:396> Frame error (port: I, count: 21) 2020-11-19 18:07:15.782560 <E> <bricklet_stack.c:396> Frame error (port: I, count: 22) 2020-11-19 18:07:15.791091 <E> <bricklet_stack.c:478> Message checksum error (port: I, count: 6) 2020-11-19 18:07:15.793300 <E> <bricklet_stack.c:396> Frame error (port: I, count: 24) 2020-11-19 18:07:15.801987 <E> <bricklet_stack.c:478> Message checksum error (port: I, count: 7) 2020-11-19 18:07:15.806293 <E> <bricklet_stack.c:478> Message checksum error (port: I, count: 8) 2020-11-19 18:07:15.810655 <E> <bricklet_stack.c:396> Frame error (port: I, count: 26) 2020-11-19 18:07:15.817000 <E> <bricklet_stack.c:396> Frame error (port: I, count: 28) 2020-11-19 18:07:15.821322 <E> <bricklet_stack.c:478> Message checksum error (port: I, count: 9) 2020-11-19 18:07:15.823546 <E> <bricklet_stack.c:396> Frame error (port: I, count: 29) 2020-11-19 18:07:15.829948 <E> <bricklet_stack.c:396> Frame error (port: I, count: 31) 2020-11-19 18:07:15.836591 <E> <bricklet_stack.c:478> Message checksum error (port: I, count: 10) 2020-11-19 18:07:15.838819 <E> <bricklet_stack.c:478> Message checksum error (port: I, count: 11) 2020-11-19 18:07:15.841033 <E> <bricklet_stack.c:396> Frame error (port: I, count: 32) 2020-11-19 18:07:15.845333 <E> <bricklet_stack.c:396> Frame error (port: I, count: 33) 2020-11-19 18:07:15.853887 <E> <bricklet_stack.c:478> Message checksum error (port: I, count: 12) 2020-11-19 18:07:15.856091 <E> <bricklet_stack.c:396> Frame error (port: I, count: 36) 2020-11-19 18:07:15.864805 <E> <bricklet_stack.c:478> Message checksum error (port: I, count: 13) 2020-11-19 18:07:15.867110 <E> <bricklet_stack.c:478> Message checksum error (port: I, count: 14) 2020-11-19 18:07:15.875601 <E> <bricklet_stack.c:396> Frame error (port: I, count: 40) 2020-11-19 18:07:15.884162 <E> <bricklet_stack.c:478> Message checksum error (port: I, count: 15) ----------------------- Solved by just installing it on the RPI OS instead, and everything is just normal...
  13. 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?
  14. 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.
  15. 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.
×
×
  • Create New...