Jump to content

xsherlock

Members
  • Gesamte Inhalte

    101
  • Benutzer seit

  • Letzter Besuch

Letzte Besucher des Profils

Der "Letzte Profil-Besucher"-Block ist deaktiviert und wird anderen Benutzern nicht angezeit.

xsherlock's Achievements

Newbie

Newbie (1/14)

  • Reacting Well Rare
  • First Post
  • Collaborator Rare
  • Dedicated Rare
  • Conversation Starter

Recent Badges

0

Reputation in der Community

  1. 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.
  2. 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.
  3. Many thanks ! Did the job. my first dimmer is done !
  4. 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.
  5. 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: tf_industrial_digital_in_4_v2_register_all_value_callback(&idi, idi_callback_handler, this); tf_industrial_digital_in_4_v2_set_all_value_callback_configuration (&idi, 100, true); Now the tricki part is the callback funcionality in the handler function static void idi_callback_handler(TF_IndustrialDigitalIn4V2 *idi, bool changed[4], bool value[4], void *user_data) { (void)idi; (void)user_data; logger.printfln("digital in state changed"); logger.printfln("Channel 0: %s", value[0] ? "true" : "false"); logger.printfln("Channel 1: %s", value[1] ? "true" : "false"); logger.printfln("Channel 2: %s", value[2] ? "true" : "false"); logger.printfln("Channel 3: %s", value[3] ? "true" : "false"); if (value[0]== 0 && value[1] == 0) { logger.printfln("00 output 0%c", '%'); tf_industrial_analog_out_v2_set_voltage(&iao, 0); } } 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
  6. xsherlock

    e-paper quirks

    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?
  7. 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.
  8. 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
  9. 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
  10. Yes I you your probe from the shop that is 2 wire. How do I connect a 2 wire PT100 with 4 wires? TIA
  11. 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?
  12. 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.
  13. 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.
  14. 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.
  15. ok installing, now, I have a 3 way valve governing 2000l of boiling hot water on that one RPi to manage
×
×
  • Neu erstellen...