xsherlock

It works in the ENEL charging platform here in italy where the charger will log you in even without the enel app installed.  I did setup that once and then reflashed a phone and it still authorizes me.  Looking forward, I have this uni campus project where a lot of chargers has to be installed and distributing people cards would be a PITA.

I just updated to the latest firmware and I still see that when NFC reader reads the tag from the smartphone it does change all the time. And it also shows only 8 bytes of the address and not all 16 as with the supplied cards.

Is there really no way to reliably identify the user by the Android  smartphone?  I think that such a  Funcionality is super  important.

Many thanks ! Did the job.  my first dimmer is done !

On 1/17/2024 at 5:26 PM, MatzeTF said:

You will have to make iao accessible to the set_iao_out() function, either by making it global or public in your module’s class.

 

Thank you for the answers,  They put me on the right track, the remainain problem is how do I exactly make the iao public or global.

Based on the Tutorial5 i declare iao in the header dimmer.h ,here it it all:

#pragma once

#include "config.h"
#include "module.h"
#include "bindings/bricklet_industrial_analog_out_v2.h"
#include "bindings/bricklet_industrial_digital_in_4_v2.h"

class Dimmer final : public IModule
{
public:
    Dimmer(){}
    void pre_setup() override;
    void setup() override;
    void register_urls() override;
    void loop() override;


    void set_bricklet_voltage(int volt_out);
    void poll_bricklet_voltage();
    void set_iao_out(uint16_t voltage);

    // ConfigRoot object to represent the color to be send to the frontend module
    ConfigRoot config;

    // Extra ConfigRoot object to represent color updates received from the frontend module
    ConfigRoot config_update;

    // ConfigRoot object to represent the button state to be send to the frontend module
    ConfigRoot state;

    
    TF_IndustrialAnalogOutV2  iao;
    TF_IndustrialDigitalIn4V2 idi;

};

and then in the code file it still fails with "undefined reference to `iao'"  only this time in our set_iao_out()

I tried adding 

extern TF_IndustrialAnalogOutV2 iao;

but that does not help.

Dear,

I have a bit of the problem programing ESP32 brick.  I try to do a standalone 0-10V dimmer with 4 buttons control. So I have 2 bricklets connected

Industrial_digital_in_4_v2 and

industrial_analog_out_v2

I did setup VS code environment with platformio and managed to program some basic functions  I can control both digital_in and analog_out corectly in the setup() 

I have a working callback that I define as following:

Now the tricki part is the callback funcionality in the handler function 

This will throw error on attempt to interact with analog_out from the digital_in callback, the very same line will work in the setup() but not

src/modules/dimmer/dimmer.cpp:26:50: error: 'iao' was not declared in this scope
         tf_industrial_analog_out_v2_set_voltage(&iao, 0);
                                                  ^~~

Can anyone tell me what is wrong here? and how to workaround here to be able do something usefull from within calback

TIA

Maciej

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?

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.

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 

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

Yes I you your probe from the shop that is 2 wire.

How do I connect  a 2 wire PT100 with 4 wires?

TIA

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?

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.   

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.

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.

ok installing, now,  I have a 3 way valve governing 2000l   of boiling hot water  on that one RPi to manage

so you say that RPI OS can fail any time if I put load on the CPU?

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...

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?

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.

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.

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.

forgot to set notifications on that post.

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 

C'mon translate that to english, I'm waiting for those proper binding for months.

Hi,

I need to read 2 x NTC 10K termistors values, Can that be done with any tinkerforge brick?

Maciej