This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
New I2C sensors supported
#41
(2021-03-03, 01:27 PM)Sailoog Wrote:
(2021-02-24, 09:07 PM)Ski_Entropy Wrote: I have a DHT11 sensor, which has similar functionality to the BME280. It seems that the BME280 is native i2C and SPI communication protocol and also easy to purchase, which I have done, since it is already supported. 
Q1: is the DHT11 not supported because its communication protocol is one-wire?
Q2: The BME680 sensor looks really cool and having a carbon monoxide, VOC, etc. monitoring capability would be beneficial. might this be a good candidate for an additional sensor in I2C?
Thank you again for the great program, always grateful!

Q1: yes, this is the list of 1W sensors supported by openplotter-gpio app:

  • DS18S20
  • DS1822
  • DS18B20
  • DS28EA00
  • DS1825/MAX31850K

Q1: DHT11 is not a 1-Wire compatible sensor - it has 1 data wire and similar resistor requirements but does not follow the same protocol as the Dalllas 1-Wire system
Reply
#42
(2021-04-26, 05:45 AM)jekyllandhyde Wrote: Rasberry Pi4, Openplotter, Signal K, etc.

I have been testing out the Adafruit INA260 sensor with Openplotter to show my house battery voltage.  I cannot get the path to appear in the Signal K data browser.   It shows as setup properly in the I2C sensors area with the correct ID (40) and path - electrical.batteries.1.voltage.  I essentially set it up in a similar way as my BME280 sensor which works great.   I thought maybe the sensor was faulty so I bought a second one and it still doesn't work.  I don't know of an easy alternative way to see sensor data (outside of SignalK).   It seems like a driver issue but I'm not technical enough to dive deep under the hood.  If someone out there is technical and can dig into this, I'll send you a sensor for free.

I added the INA260 to openplotter-i2c app but never tested it because I do not have any sensor. Please contact me by private to give you my address and get that sensor if possible. Thanks.
Reply
#43
(2021-04-15, 11:44 PM)jekyllandhyde Wrote: I have Openplotter.I2C.BME280 (I2C sensor) mapped to environment.inside.relativeHumidity.   Signal K's data browser shows 33.5 as the ratio - but the sensor is reporting percentage.  When I view instrument panel it of course multiplies by 100 and shows me 3340%.   Is there a way to divide the sensor's raw data by 100 at source so that Signal K has the proper ratio?
Would like to get instrument panel to show 33.5% which is what is correct for humidity.

Cheers,  Adam

you are right, according to SK specification relativeHumidity unit is "ratio" and we are sending % fromn openplotter-i2c app. This is a bug a it should be fixed. Do you think just dividing the sensor raw value (%) by 100 will fix this?
Reply
#44
(2021-04-28, 01:00 PM)Sailoog Wrote:
(2021-04-15, 11:44 PM)jekyllandhyde Wrote: I have Openplotter.I2C.BME280 (I2C sensor) mapped to environment.inside.relativeHumidity.   Signal K's data browser shows 33.5 as the ratio - but the sensor is reporting percentage.  When I view instrument panel it of course multiplies by 100 and shows me 3340%.   Is there a way to divide the sensor's raw data by 100 at source so that Signal K has the proper ratio?
Would like to get instrument panel to show 33.5% which is what is correct for humidity.

Cheers,  Adam

you are right, according to SK specification relativeHumidity unit is "ratio" and we are sending % fromn openplotter-i2c app. This is a bug a it should be fixed. Do you think just dividing the sensor raw value (%) by 100 will fix this?

I think it will fix it!
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)