sedtronic light intensity sensor

TomasKnot

It turns out that OWFS know about any VCURR value for DS2438. (as per http://owfs.org/index.php?page=ds2438) This poses us with a rather sizable problem - do you believe that any of the other variable as per the OWFS documentation would be appropriate?

TomasKnot

After further investigation the VIS value is similar to VCURR - VCURR is not a value standard for owfs. I will make EVOK provide the VIS value, but unfortunately the VCURR value depends on the resistor used - I attempted to contant mister Sedlacek regarding this, but I hadn't gotten a reply as of yet.

juntiedt

HiTomas,
in the library, that I mentioned above, they called Vcurr just I which means current. As sedtronic said, I = 0 means 0% and I=0,250 mens 100%. Knowing this, I don't care about the resistor.

Also have a look at the many conversation calculations in the library above. Actualy one can read the code for the formula from the 1w device.

TomasKnot

You should be able to use the latest owclient.py to read the VCurr/VIS value. After a call to Mr. Sedlacek, the value and calculation is the same, just the naming scheme is different.

To be clear I should note VIS is not I, but rather voltage delta between the two VSens inputs into ds2438 (http://pdf1.alldatasheet.com/datasheet-pdf/view/58618/DALLAS/DS2438.html). To compute I one does in fact need the resistor value.

I did have a look at the website you sent me, but while interesting it a) does not have all the sensors that can be connected to the DS2438 and b) 1Wire does not have any way of identifying which sensors are connected to it, which means the user would have to specify which formula to use anyhow.

Apologies for it being so difficult to read the value. The sensor has been primarily tested with Mervis rather than EVOK.

juntiedt

i just changed owclient.py in /opt/evok/ but had no success. The http Client interface crashes when now reading ds2438 device.

TomasKnot

@juntiedt

That's odd. I haven't had that happen myself when I tested the change. In fact the client interface does not read any of the sensor data aside from temperature and humidity, here:

case "1wdevice": {
	if (device_properties["typ"] == "DS2438") {
		device_properties["device_name"] = "" + device_properties["typ"] + " - " + circuit_display_name;
        if (msg.value == null) {
        	device_properties["value"] = "N/A";
        	device_properties["humidity"] = "N/A";
        }
        else {
        	device_properties["value"] = msg.temp.toFixed(1);
        	device_properties["humidity"] = msg.humidity.toFixed(1);
        	device_properties["unit"] = "°C";
        }   	
	} else {
		device_properties["device_name"] = "Sensor " + device_properties["typ"] + " - " + circuit_display_name;
        if (msg.value == null) {
        	device_properties["value"] = "N/A";
        }
        else {
        	device_properties["value"] = msg.value.toFixed(1);
        	device_properties["unit"] = "°C";
        }
	}
	break;
}

When you say it crashes, what do you mean exactly?

juntiedt

Hi Tomas,

this is what I get with the new owclient.py when calling temp device:

{'code': 500, 'status': 'error', 'message': 'Internal Server Error'}

All other devices are ok

TomasKnot

I've now pushed a fix for the display issue. The device type of the DS2438 has been changed to temp, but the interface which verifies the requests wasn't updated properly for it, and the GUI had trouble dealing with it as well.

Replacing the devices.py (in /opt/evok) and main.js (in /var/www/evok/js/) with the latest versions should do the trick now.

juntiedt

Hi Tomas,

thanks for your fast response, but that's what I get now:

Traceback (most recent call last):
  File "/home/pi/part_10/webapp/UniPi_devices.py", line 9, in <module>
    records = unipi.get_all_devices("j")
  File "/home/pi/part_10/webapp/UniPi_interface_class.py", line 56, in get_all_devices
    res = urllib.request.urlopen(url_rest).read()
  File "/usr/lib/python3.5/urllib/request.py", line 163, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/lib/python3.5/urllib/request.py", line 472, in open
    response = meth(req, response)
  File "/usr/lib/python3.5/urllib/request.py", line 582, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib/python3.5/urllib/request.py", line 510, in error
    return self._call_chain(*args)
  File "/usr/lib/python3.5/urllib/request.py", line 444, in _call_chain
    result = func(*args)
  File "/usr/lib/python3.5/urllib/request.py", line 590, in http_error_default
    raise HTTPError(req.full_url, code, msg, hdrs, fp)
urllib.error.HTTPError: HTTP Error 502: Bad Gateway

Hope the problem is not to bad ...

TomasKnot

I tested it with a clean Raspberry Pi image using the latest GH master. You shouldn't need to use a clean image, however; it was more to check that everything else works as it should.

It might help if you replace all of EVOK source code with the latest version (i.e. the .py files, evok.py and schemas.py in particular). I've tested both the REST and WebSocket API so it should work. The error could be from verification code in evok.py/schemas.py, where if you use a newer version of the other files they fail to work properly together.

juntiedt

Hi Tomas,

after reinstalling evok everything is ok!
Many thanks for your professional support.
have alook at my trainings unipi control panel 188.194.138.174
temp devices get updated every minute and the other devices uses evok websocket events.

Hannes

TomasKnot

@juntiedt said in sedtronic light intensity sensor:

Hi Tomas,

after reinstalling evok everything is ok!
Many thanks for your professional support.
have alook at my trainings unipi control panel 188.194.138.174
temp devices get updated every minute and the other devices uses evok websocket events.

Hannes

That looks really excellent! Glad you got it working well now.

Apologies for the issues with EVOK.
Kind Regards
Tomas