Evok problem getting I/O boards data

tempurpri

Hello,

I've had some problems with evok in the past, which I was finally able to solve with a fresh OS installation and by adapting ports before installing Codesys (which I need on the Neuron S103 that I have).

See the linked discussion for further information:
https://forum.unipi.technology/topic/516/evok-high-cpu-usage/10

Recently however another problem appeared.
Evok (service) is running Nginx (service) is running, however I'm unable to access the I/Os through the web page neither throught the modbus server. Both were working for me.

As far as I can remember the only thing that was done during this time was the usual apd-get update / apt-get upgrade.
Unfortunately I cannot pinpoint exactly when the problem appeared because I don't need this functionality all the time.

To make thinfs clear, here is how the web page appears:

No inputs or outputs are accessible.

I'm supplying the information that might help shed some light on the situation if anyone can help

lsmod

Module                  Size  Used by
can_raw                 7426  0
can                    31515  1 can_raw
w1_therm                6401  0
w1_gpio                 4818  0
ds2482                  4427  0
wire                   32619  3 ds2482,w1_gpio,w1_therm
cn                      5889  1 wire
at24                    7587  0
spidev                  7373  0
nvmem_core             13774  1 at24
rtc_ds1307             13908  0
hwmon                  10552  1 rtc_ds1307
brcmfmac              292632  0
brcmutil                9863  1 brcmfmac
cfg80211              544545  1 brcmfmac
rfkill                 20851  2 cfg80211
i2c_bcm2835             7167  0
spi_bcm2835             7596  0
bcm2835_gpiomem         3940  0
uio_pdrv_genirq         3923  0
fixed                   3285  0
uio                    10204  1 uio_pdrv_genirq
i2c_bcm2708             5994  0
i2c_dev                 6913  0
ip_tables              13161  0
x_tables               20578  1 ip_tables
ipv6                  408900  27

i2cdetect 1

WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1.
I will probe address range 0x03-0x77.
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- UU
70: -- -- -- -- -- -- -- --

ps -fax

  PID TTY      STAT   TIME COMMAND
    2 ?        S      0:00 [kthreadd]
    3 ?        S      0:00  \_ [ksoftirqd/0]
    5 ?        S<     0:00  \_ [kworker/0:0H]
    6 ?        S      0:00  \_ [kworker/u8:0]
    7 ?        S      0:00  \_ [rcu_sched]
    8 ?        S      0:00  \_ [rcu_bh]
    9 ?        S      0:00  \_ [migration/0]
   10 ?        S<     0:00  \_ [lru-add-drain]
   11 ?        S      0:00  \_ [cpuhp/0]
   12 ?        S      0:00  \_ [cpuhp/1]
   13 ?        S      0:00  \_ [migration/1]
   14 ?        S      0:00  \_ [ksoftirqd/1]
   16 ?        S<     0:00  \_ [kworker/1:0H]
   17 ?        S      0:00  \_ [cpuhp/2]
   18 ?        S      0:00  \_ [migration/2]
   19 ?        S      0:00  \_ [ksoftirqd/2]
   21 ?        S<     0:00  \_ [kworker/2:0H]
   22 ?        S      0:00  \_ [cpuhp/3]
   23 ?        S      0:00  \_ [migration/3]
   24 ?        S      0:00  \_ [ksoftirqd/3]
   26 ?        S<     0:00  \_ [kworker/3:0H]
   27 ?        S      0:00  \_ [kdevtmpfs]
   28 ?        S<     0:00  \_ [netns]
   29 ?        S      0:00  \_ [khungtaskd]
   30 ?        S      0:00  \_ [oom_reaper]
   31 ?        S<     0:00  \_ [writeback]
   32 ?        S      0:00  \_ [kcompactd0]
   33 ?        S<     0:00  \_ [crypto]
   34 ?        S<     0:00  \_ [bioset]
   35 ?        S<     0:00  \_ [kblockd]
   36 ?        S<     0:00  \_ [watchdogd]
   38 ?        S<     0:00  \_ [rpciod]
   39 ?        S<     0:00  \_ [xprtiod]
   40 ?        S      0:00  \_ [kswapd0]
   41 ?        S<     0:00  \_ [vmstat]
   42 ?        S<     0:00  \_ [nfsiod]
   52 ?        S<     0:00  \_ [kthrotld]
   53 ?        S<     0:00  \_ [bioset]
   54 ?        S<     0:00  \_ [bioset]
   55 ?        S<     0:00  \_ [bioset]
   56 ?        S<     0:00  \_ [bioset]
   57 ?        S<     0:00  \_ [bioset]
   58 ?        S<     0:00  \_ [bioset]
   59 ?        S<     0:00  \_ [bioset]
   60 ?        S<     0:00  \_ [bioset]
   61 ?        S<     0:00  \_ [bioset]
   62 ?        S<     0:00  \_ [bioset]
   63 ?        S<     0:00  \_ [bioset]
   64 ?        S<     0:00  \_ [bioset]
   65 ?        S<     0:00  \_ [bioset]
   66 ?        S<     0:00  \_ [bioset]
   67 ?        S<     0:00  \_ [bioset]
   68 ?        S<     0:00  \_ [bioset]
   69 ?        S<     0:00  \_ [bioset]
   70 ?        S<     0:00  \_ [bioset]
   71 ?        S<     0:00  \_ [bioset]
   72 ?        S<     0:00  \_ [bioset]
   73 ?        S<     0:00  \_ [bioset]
   74 ?        S<     0:00  \_ [bioset]
   75 ?        S<     0:00  \_ [bioset]
   76 ?        S<     0:00  \_ [bioset]
   77 ?        S<     0:00  \_ [iscsi_eh]
   78 ?        S<     0:00  \_ [dwc_otg]
   80 ?        S<     0:00  \_ [DWC Notificatio]
   81 ?        S<     0:00  \_ [VCHIQ-0]
   82 ?        S<     0:00  \_ [VCHIQr-0]
   83 ?        S<     0:00  \_ [VCHIQs-0]
   84 ?        S      0:00  \_ [VCHIQka-0]
   85 ?        S<     0:00  \_ [SMIO]
   87 ?        S      0:00  \_ [irq/92-mmc1]
   90 ?        S<     0:00  \_ [bioset]
   91 ?        S      0:01  \_ [mmcqd/0]
   93 ?        S      0:00  \_ [jbd2/mmcblk0p2-]
   94 ?        S<     0:00  \_ [ext4-rsv-conver]
   96 ?        S<     0:00  \_ [ipv6_addrconf]
  147 ?        S      0:00  \_ [kworker/3:2]
  212 ?        S      0:00  \_ [spi0]
  247 ?        S<     0:00  \_ [cfg80211]
  249 ?        S<     0:00  \_ [brcmf_wq/mmc1:0]
  250 ?        S      0:00  \_ [brcmf_wdog/mmc1]
  285 ?        S      0:00  \_ [w1_bus_master1]
  479 ?        S<     0:00  \_ [kworker/3:1H]
  616 ?        S<     0:00  \_ [kworker/1:1H]
  721 ?        S      0:00  \_ [kworker/1:0]
  722 ?        S<     0:00  \_ [kworker/0:1H]
  893 ?        S      0:00  \_ [kworker/1:1]
  904 ?        S      0:00  \_ [kworker/3:0]
  909 ?        S<     0:00  \_ [kworker/2:1H]
  926 ?        S      0:00  \_ [kworker/0:0]
  991 ?        S      0:00  \_ [kworker/0:1]
 1092 ?        S      0:00  \_ [kworker/u8:1]
 1100 ?        S      0:00  \_ [kworker/2:0]
 1112 ?        S      0:00  \_ [kworker/2:2]
 1118 ?        S      0:00  \_ [kworker/2:1]
    1 ?        Ss     0:02 /sbin/init
  119 ?        Ss     0:00 /lib/systemd/systemd-journald
  152 ?        Ss     0:00 /lib/systemd/systemd-udevd
  317 ?        Ssl    0:00 /lib/systemd/systemd-timesyncd
  359 ?        Ss     0:00 /usr/sbin/cron -f
  360 ?        Ss     0:00 avahi-daemon: running [S103-sn344.local]
  390 ?        S      0:00  \_ avahi-daemon: chroot helper
  362 ?        Ss     0:00 /lib/systemd/systemd-logind
  368 ?        Ss     0:01 /opt/neuron-bin/neuron_tcp_server -p 502 --check-firmware
  369 ?        Ss     0:00 /usr/sbin/thd --triggers /etc/triggerhappy/triggers.d/ --socket /run/thd.socket --user nobody --deviceglob /dev/input/event*
  375 ?        Ss     0:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
  393 ?        Ssl    0:00 /usr/sbin/rsyslogd -n
  395 ?        SNsl   1:04 node-red
  413 ?        Ssl    0:01 /sbin/apcupsd
  469 tty1     Ss+    0:00 /sbin/agetty --noclear tty1 linux
  486 ?        Ss     0:00 /sbin/netplugd -p /var/run/netplugd.pid
  492 ?        S      0:01 /opt/codesys/bin/codesyscontrol.bin /etc/CODESYSControl.cfg
  505 ?        Sl     8:07  \_ /opt/codesys/bin/codesyscontrol.bin /etc/CODESYSControl.cfg
  497 ?        Ss     0:00 /usr/sbin/sshd -D
  741 ?        Ss     0:00  \_ sshd: pi [priv]
  756 ?        S      0:01  |   \_ sshd: pi@pts/0
  759 pts/0    Ss     0:00  |       \_ -bash
  775 pts/0    S+     1:33  |           \_ htop
  782 ?        Ss     0:00  \_ sshd: pi [priv]
  792 ?        S      0:00      \_ sshd: pi@pts/1
  795 pts/1    Ss     0:01          \_ -bash
 1119 pts/1    R+     0:00              \_ ps -fax
  598 ?        Ss     0:00 /sbin/dhclient -4 -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases -I -df /var/lib/dhcp/dhclient6.eth0.leases eth0
  746 ?        Ss     0:00 /lib/systemd/systemd --user
  749 ?        S      0:00  \_ (sd-pam)
  977 ?        Ssl    0:22 /usr/bin/python /opt/evok/evok.py
  979 ?        Z      0:00  \_ [python] <defunct>
  986 ?        Ss     0:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
  987 ?        S      0:00  \_ nginx: worker process
  988 ?        S      0:00  \_ nginx: worker process
  989 ?        S      0:00  \_ nginx: worker process
  990 ?        S      0:00  \_ nginx: worker process

/boot/config.txt (having the dtoverlay=neuron-spu-new was not problematic during this time .. I could comment it out though if that would welp for some test ?)

gpu_mem=32
dtparam=i2c_arm=on,watchdog=on

dtoverlay=i2c-rtc,mcp7941x

# disable it on Unipi 1.x (gpio24, 25!)
dtoverlay=neuron-spi-new
dtoverlay=neuronee
#dtoverlay=unipiee

#Enable kernel driver for I2c OneWire Master
dtoverlay=ds2482

#remove dependency of spi-clock on system freq
core_freq=250

#BT enabled on RPi3 swaps UART (ttyAMA) and miniUART ttyS0.
dtoverlay=pi3-disable-bt

#WIFI disabled
#dtoverlay=pi3-disable-wifi


# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details

# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1

# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
#disable_overscan=1

# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720

# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1

# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2

# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4

# uncomment for composite PAL
#sdtv_mode=2

#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800

# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
#dtparam=audio=off

eeprom verification

~ $ sudo grep S103 /sys/bus/i2c/devices/1-0057/eeprom
Binary file /sys/bus/i2c/devices/1-0057/eeprom matches

This time however I have a lot of errors in /var/log/evok.log (all the same thought)

2018-01-21 22:09:32,851 - evok - ERROR - 'NoneType' object has no attribute 'do_scan'
Traceback (most recent call last):
  File "/opt/evok/neuron.py", line 217, in scan_boards
    yield self.modbus_cache_map.do_scan()
AttributeError: 'NoneType' object has no attribute 'do_scan'
2018-01-21 22:09:33,354 - evok - ERROR - 'NoneType' object has no attribute 'do_scan'
Traceback (most recent call last):
  File "/opt/evok/neuron.py", line 217, in scan_boards
    yield self.modbus_cache_map.do_scan()
AttributeError: 'NoneType' object has no attribute 'do_scan'
2018-01-21 22:09:33,857 - evok - ERROR - 'NoneType' object has no attribute 'do_scan'
Traceback (most recent call last):
  File "/opt/evok/neuron.py", line 217, in scan_boards
    yield self.modbus_cache_map.do_scan()
AttributeError: 'NoneType' object has no attribute 'do_scan'
2018-01-21 22:09:34,360 - evok - ERROR - 'NoneType' object has no attribute 'do_scan'
Traceback (most recent call last):
  File "/opt/evok/neuron.py", line 217, in scan_boards
    yield self.modbus_cache_map.do_scan()
AttributeError: 'NoneType' object has no attribute 'do_scan'
2018-01-21 22:09:34,862 - evok - ERROR - 'NoneType' object has no attribute 'do_scan'
Traceback (most recent call last):
  File "/opt/evok/neuron.py", line 217, in scan_boards
    yield self.modbus_cache_map.do_scan()
AttributeError: 'NoneType' object has no attribute 'do_scan'

It seems that the python script fails in finding the "boards" for the i/o, but I'm not able to find out why.

Please help, I have a running application on this board and have to connect the I/O signals to it, but I came to a stop with this problem.

TomasKnot

Do you have the Neuron tcp server installed and running? (you can check with "systemctl status neurontcp", or using some utility such as e.g. qModMaster to connect to the Neuron ip address, port 502). It might also help us to know what your Evok config looks like. The message simply means that Evok can't find any recognisable Neuron subdevices on the SPI bus, which requires the Modbus daemon to be running.

I should mention that it might be easier to use Codesys with TCP/Modbus rather than Evok, but I don't know enough about your intended use to say it for certain. We are also in the finishing stages of implementing native drivers for the digital and analog inputs/outputs as Linux GPIOs and IIOs respectively.

The other thing is that we should be releasing an actual Codesys Neuron package with 3S (developers of Codesys) support and approval within two or three weeks.

tempurpri

Yes, Neuron tcp is installed and running (as it was from the original open-source OS).

~$systemctl status neurontcp

● neurontcp.service - Unipi Neuron Modbus/Tcp Server
   Loaded: loaded (/opt/neuron-bin/neurontcp.service; enabled; vendor preset: en
   Active: active (running) since Mon 2018-01-22 21:58:30 UTC; 1 day 2h ago
 Main PID: 362 (neuron_tcp_serv)
   CGroup: /system.slice/neurontcp.service
           └─362 /opt/neuron-bin/neuron_tcp_server -p 502 --check-firmware

Jan 22 21:58:30 S103-sn344 systemd[1]: Started Unipi Neuron Modbus/Tcp Server.

evok.conf

#!!! Do not use '#' for comments !!!

[MAIN]
config_version = 2.4					; Configuration file version, DO NOT CHANGE!
use_schema_verification = False			; Enabling this will deny any requests that do not match the JSON Schema; NOTE THAT THIS RESULTS IN A SIGNIFICANT INCREASE IN LATENCY AND SHOULD NOT BE USED EXCEPT FOR TESTING
log_level = ERROR   					; Minimum severity of messages to be logged; one of INFO, DEBUG, WARNING, ERROR, CRITICAL
log_file = /var/log/evok.log			; Log file to use; will be cleared on boot
port = 8085								; !!! Internal API port - only change if you are certain you know what you are doing; FOR OUR WEB INTERFACE THE PORT SHOULD BE CHANGED IN "/etc/evok-nginx.conf" INSTEAD !!!
webhook_enabled = False					; Enables webhook notification - see e.g. https://sendgrid.com/blog/whats-webhook/
webhook_address = http://127.0.0.1:85   ; Put your server endpoint address here (e.g. http://123.123.123.123:/wh )
webhook_device_mask = ["input","wd"]	; List of device types to notify on (written as a JSON list) - adding AI will generate a large amount of messages!
webhook_complex_events = False			; EVOK will send POST requests with the same data as WebSocket, rather than an empty GET request
wifi_control_enabled = False			; !!! REQUIRES THE UNIPIAP WIFI CONTROLLER TO BE INSTALLED !!! Will allow evok to control the internal Neuron wifi 
soap_server_enabled = False				; Enables the simple SOAP server; use only if you need the functionality
soap_server_port = 8081					; !!! IF SOAP SERVER IS ENABLED, THIS PORT NEEDS TO BE UNIQUE (i.e. different from the port setting above) !!!

[NEURON_1]
global_id = 1							; Mandatory, REQUIRED TO BE UNIQUE
allow_register_access = True 			; Optional, False default
scan_frequency = 2 						; Optional, 1 default
scan_enabled = True 					; Optional, True default

; Below you can find examples for connecting devices over UART; first example is a Neuron extension while the second is a custom third-party device
; Devices sharing a port use the port settings of the first device on that port (baud rate, parity, stopbits)
; !!!Note that device_name has to match a filename in the /etc/hw_definitions directory!!! See /etc/hw_definitions/DOMAT MMIO.yaml for an example

;[EXTENSION_1]
;global_id = 2							; Mandatory, REQUIRED TO BE UNIQUE
;device_name = xS10						; Mandatory
;modbus_uart_port = /dev/extcomm/0/0 	; Mandatory
;neuron_uart_circuit = 1_01				; Optional, allows associating extensions with specific Neuron UART-over-Modbus ports (not possible for non-Modbus UART ports, e.g. /dev/ttyUSB0 or /dev/ttyS0)
;allow_register_access = True 			; Optional, False default, is mandatory with third-party devices
;address = 15 							; Optional, 15 default
;scan_frequency = 2 					; Optional, 1 default
;scan_enabled = True 					; Optional, True default
; Note that the following settings will be inherited by other devices sharing the same port, i.e. /dev/extcomm/0/0
;baud_rate = 19200						; Optional, NEEDS UNIPI IMAGE TO WORK! USE API TO CONFIGURE UART MANUALLY IF USING STANDARD RASPBIAN
;parity = N								; Optional, NEEDS UNIPI IMAGE TO WORK! USE API TO CONFIGURE UART MANUALLY IF USING STANDARD RASPBIAN
;stop_bits = 1							; Optional, NEEDS UNIPI IMAGE TO WORK! USE API TO CONFIGURE UART MANUALLY IF USING STANDARD RASPBIAN

;[EXTENSION_2]
;global_id = 3							; Mandatory, REQUIRED TO BE UNIQUE
;device_name = CUSTOM MODBUS DEVICE		; Mandatory
;modbus_uart_port = /dev/extcomm/0/0 	; Mandatory
;neuron_uart_circuit = 1_01				; Optional, allows associating extensions with specific Neuron UART-over-Modbus ports (not possible for non-Modbus UART ports, e.g. /dev/ttyUSB0 or /dev/ttyS0)
;allow_register_access = True 			; Mandatory with third-party devices
;address = 1 							; Optional, 15 default
;scan_frequency = 2 					; Optional, 1 default
;scan_enabled = True 					; Optional, True default

[OWBUS_1]
owbus = /dev/i2c-1 --i2c=/dev/i2c-1:ALL     		; Scanned bus (--i2c=/dev/i2c-1:ALL or localhost:2122 or 'u' for USB dongle)
interval = 3          					; [s] Default sensor reading
scan_interval = 300    					; [s] How often is scanning done

;Example of 1W-4R/4DI extension module, 1W-8R is almost the same, only with inputs instead of relays
;
; - Map a new 1Wire sensor with the appropriate address, type and interval
; - The syntax can be either SENSOR or 1WDEVICE
; - Setting the correct reading interval is crucial to achieve ideal performance; the default interval is 15s
;
;[1WDEVICE_2]
;bus = 1
;address = 29F39A17000000BC
;type = DS2408
;interval = 1
;
;[1WRELAY_10]
;sensor = 2
;pin = 0
;
;[1WRELAY_11]
;sensor = 2
;pin = 1
;
;[1WRELAY_12]
;sensor = 2
;pin = 2
;
;[1WRELAY_13]
;sensor = 2
;pin = 3
;
;[1WINPUT_20]
;sensor = 2
;pin = 4
;
;[1WINPUT_21]
;sensor = 2
;pin = 5
;
;[1WINPUT_22]
;sensor = 2
;pin = 6
;
;[1WINPUT_23]
;sensor = 2
;pin = 7

evok-nginx.conf


server {
	listen 85 default_server;
	server_name  _;

	#ssl on;
	#ssl_certificate      /etc/nginx/democert.pem;
	#ssl_certificate_key  /etc/nginx/democert.key;

	access_log  /var/log/evok.access.log;
	root /var/www/evok;

	location / {
	    index index.html;	    
	}

	location /ws {
		proxy_pass http://localhost:8085;
		proxy_set_header Host $host:$server_port;
		proxy_http_version 1.1;
		proxy_set_header Upgrade $http_upgrade;
		proxy_set_header Connection "upgrade";
		proxy_buffering off;
		proxy_cache off;
		#send_timeout 120;
		proxy_read_timeout 180;
		#proxy_set_header X-Real-IP $remote_addr;
	}

	location /rest {
		proxy_pass http://localhost:8085;
		proxy_set_header Host      $host:$server_port;
		#proxy_set_header X-Real-IP $remote_addr;
	}
	
	location /json {
		proxy_pass http://localhost:8085;
		proxy_set_header Host      $host:$server_port;
		#proxy_set_header X-Real-IP $remote_addr;
	}
	
}

I can see the tcp port 502 opened at 127.0.0.1

I also know that Modbus is the better way to go .. in fact that was the way I also had it working (as you can probably see from the setting in evok.conf), but modbus access went down too - it's not working either. Connecting to the modbus server, trying to read one register at address 0 I only get a modbus exception error code 2.

I noticed one additional error as shown below, specifically if it means anything new...doubt it though.

~ $ systemctl status evok
● evok.service - Evok Modbus/Websocket/Rpc Server
   Loaded: loaded (/etc/systemd/system/evok.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2018-01-24 00:42:03 UTC; 3s ago
 Main PID: 1807 (python)
   CGroup: /system.slice/evok.service
           └─1807 /usr/bin/python /opt/evok/evok.py

Jan 24 00:42:03 S103-sn344 systemd[1]: Started Evok Modbus/Websocket/Rpc Server.
Jan 24 00:42:07 S103-sn344 OWFS[1812]: DEFAULT: owlib.c:(52) No valid 1-wire buses found

I guess that if the modbus deamon isn't working properly the problem is somewhere deeper.

(Modbus TCP access to I/Os was fine and fast whle it was forking. Now it's not. But I really look forward to accessing the I/Os directly from Codesys. Alas deadlines are deadlines and I have to get this working at least as it was about a month ago.)

Do you think it's possible a system update (as I mentioned i DID perform a apt-get update / upgrade during this time) might have introduced some sort of an incompatibility ? Do you have any other suggestion ?

FYI last time (if you check my other post) reinstalling evok / neurontcp didn't help at all....but then there were what seemed other issues.

Thanks for your help

TomasKnot

Oh right, I know what the issue is - we've encountered the same thing when trying to get Codesys working - Codesys has its own 1Wire driver which is not compatible with other ones out of the box - meaning that only Codesys can communicate with 1Wire devices when it is installed, including the I/O board.

This is a known issue with Codesys not supporting OWFS. At least not fully and officially, there are hacks to get it working somewhat (by having the Codesys driver emulate a virtual 1Wire bus master, which then OWFS connects to - this causes various issues however), but they are unsupported.

Our solution for Codesys was to disable EVOK 1Wire (and Mervis, which is not compatible 1Wire-wise as well) when Codesys installation is detected.

You might wish try to get the board working through Codesys 1Wire instead.

tomas_hora

@tempurpri Codesys for Neurons will be soon released (also discussed here https://forum.unipi.technology/topic/549/codesys-on-unipi-neuron-installing-issues-help-please )

Andrew Watson

Hi,

Sorry to hijack this thread a little, but it seems that I have a very similar problem, so maybe this can help both of us?
I get the same empty web interface, but I'm not using Codesys as far as I know.

I started with a bare install of Raspbian stretch lite, installed a few basic things

apt-get install git vim supervisor python-gpiozero

Then followed the installation instructions from the evok git repository.

I get the same error:

$ tail /var/log/evok.log

2018-01-24 11:03:13,781 - evok - ERROR - 'NoneType' object has no attribute 'do_scan'
Traceback (most recent call last):
  File "/opt/evok/neuron.py", line 225, in scan_boards
    yield self.modbus_cache_map.do_scan()
AttributeError: 'NoneType' object has no attribute 'do_scan'
2018-01-24 11:03:14,283 - evok - ERROR - 'NoneType' object has no attribute 'do_scan'
Traceback (most recent call last):
  File "/opt/evok/neuron.py", line 225, in scan_boards
    yield self.modbus_cache_map.do_scan()
AttributeError: 'NoneType' object has no attribute 'do_scan'

status looks ok to me :

$ systemctl status evok

● evok.service - Evok Modbus/Websocket/Rpc Server
   Loaded: loaded (/etc/systemd/system/evok.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2018-01-24 11:03:18 UTC; 3min 50s ago
 Main PID: 340 (python)
   CGroup: /system.slice/evok.service
           ├─340 /usr/bin/python /opt/evok/evok.py
           └─464 /usr/bin/python /opt/evok/evok.py

Jan 24 11:03:44 unipi01 OWFS[464]: DEFAULT: ow_reconnect.c:(72) DS2482-100 bus master reconnected
Jan 24 11:04:11 unipi01 OWFS[464]: DEFAULT: ow_reconnect.c:(72) DS2482-100 bus master reconnected

Here are the open ports:

$ netstat -le
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode
tcp        0      0 0.0.0.0:ssh             0.0.0.0:*               LISTEN      root       12789
tcp        0      0 0.0.0.0:502             0.0.0.0:*               LISTEN      root       9194
tcp        0      0 0.0.0.0:http            0.0.0.0:*               LISTEN      root       12806
tcp        0      0 0.0.0.0:http-alt        0.0.0.0:*               LISTEN      root       10395
tcp6       0      0 [::]:ssh                [::]:*                  LISTEN      root       12791
tcp6       0      0 [::]:http-alt           [::]:*                  LISTEN      root       10396
udp        0      0 0.0.0.0:mdns            0.0.0.0:*                           avahi      10357
udp        0      0 0.0.0.0:51138           0.0.0.0:*                           avahi      10359
udp        0      0 0.0.0.0:bootpc          0.0.0.0:*                           root       9499
udp6       0      0 [::]:mdns               [::]:*                              avahi      10358
udp6       0      0 [::]:56078              [::]:*                              avahi      10360
raw6       0      0 [::]:ipv6-icmp          [::]:*                  7           root       9502
Active UNIX domain sockets (only servers)
Proto RefCnt Flags       Type       State         I-Node   Path
unix  2      [ ACC ]     STREAM     LISTENING     11523    /run/user/1000/systemd/private
unix  2      [ ACC ]     STREAM     LISTENING     12867    /tmp/tmux-1000/default
unix  2      [ ACC ]     STREAM     LISTENING     11528    /run/user/1000/gnupg/S.gpg-agent
unix  2      [ ACC ]     STREAM     LISTENING     11531    /run/user/1000/gnupg/S.gpg-agent.ssh
unix  2      [ ACC ]     STREAM     LISTENING     11533    /run/user/1000/gnupg/S.gpg-agent.extra
unix  2      [ ACC ]     STREAM     LISTENING     11535    /run/user/1000/gnupg/S.gpg-agent.browser
unix  2      [ ACC ]     STREAM     LISTENING     10769    /var/run/supervisor.sock.530
unix  2      [ ACC ]     STREAM     LISTENING     9275     /var/run/avahi-daemon/socket
unix  2      [ ACC ]     STREAM     LISTENING     9278     /var/run/dbus/system_bus_socket
unix  2      [ ACC ]     STREAM     LISTENING     9281     /run/thd.socket
unix  2      [ ACC ]     STREAM     LISTENING     9399     /var/run/dhcpcd.sock
unix  2      [ ACC ]     STREAM     LISTENING     9401     /var/run/dhcpcd.unpriv.sock
unix  2      [ ACC ]     STREAM     LISTENING     6355     /run/systemd/private
unix  2      [ ACC ]     SEQPACKET  LISTENING     6369     /run/udev/control
unix  2      [ ACC ]     STREAM     LISTENING     6372     /run/systemd/fsck.progress
unix  2      [ ACC ]     STREAM     LISTENING     6375     /run/systemd/journal/stdout

Rebooting and restarting evok (via sudo service evok restart) doesn't help.

Andrew Watson

Some additional information, since I had time. I flashed a new sd card with a brand new raspbian stretch lite image (latest version, 2017-11-29)

installed git and updated the system

sudo -s
apt-get install git
apt-get update && apt-get upgrade -y && apt-get dist-upgrade -y
raspi-config and changed the hostname

Then installed the latest evok version (from commit 8a14c95 it seems).

Selected website port 80
Internal API port 8080
Install for Unipi Neuron (I have the S103)
No WiFi
Reboot

And this time it works... I don't know if this is due to something that was changed in the last commit (between 11am and 1.30pm today) or simply not installing the gpiozero library.

tempurpri

@tomas_knot The incompatibility with Codesys (the one you mention and the port incompatibility) would be an understandeable reason for the problems I have....had I not managed to have a working setup of Codesys for raspberry and evok running in the last month.

Unless the 1-wire incompatibility between the two only becomes problematic with time (I'm not sure how that could be), then that was not the case for me. Just to make it clear Codesys and digital signal readout worked for me ... Modbus acces and the web interface. I needed that functionality only occasionally, so I'm not sure when it stopped working, but it was during the last month. Neither Codesys nor evok were re-installed nor was there any change in their configuration.

I'm trying to find out what happened and especially try to make it work again.

@tomas_knot @tomas_hora I understand that proper codesys integration is coming, but unless it's coming during this week it won't help my application. Unfortunately that's the timeframe I'm looking at, nothing to do with with Unipi itself.

OK, so if codesys 1 wire driver is the suspect, is there a way to check that and maybe disable it within the Codesys editor ?

TomasKnot

@Andrew-Watson said in Evok problem getting I/O boards data:

Some additional information, since I had time. I flashed a new sd card with a brand new raspbian stretch lite image (latest version, 2017-11-29)

installed git and updated the system
sudo -s
apt-get install git
apt-get update && apt-get upgrade -y && apt-get dist-upgrade -y
raspi-config and changed the hostname
Then installed the latest evok version (from commit 8a14c95 it seems).

Selected website port 80

Internal API port 8080

Install for Unipi Neuron (I have the S103)

No WiFi

Reboot

And this time it works... I don't know if this is due to something that was changed in the last commit (between 11am and 1.30pm today) or simply not installing the gpiozero library.

It's quite likely it may be the GPIOZero library. Generally speaking software connected to hardware in a direct manner (with its own drivers etc.) is considerably less compatible among itself than other software. We test EVOK internally on clean Raspbian, as well as with our own image, which is based on the Raspbian Zero; for these combinations, along with some simple software (in fact EVOK installs vim itself), the software does pass testing (with occasional edge issues e.g. the light sensor issue recently).

As to a guess why the GPIOZero library could be causing issues - we use 4 of the GPIO lines on the RPi to expand the primary SPI bus with interrupts and an extra device select slot. This (among other things) is done through the device overlay installed by EVOK, but it's possible that other software (at least one which is set up under root privileges) might change it, particularly if it deals with GPIO functionality.

The latest commits only changed functionality related to the Sedtronic WTS DS2438 1Wire sensor, so it's very unlikely to have caused the problem. The issue you (and @tempurpri) are seeing is due to the expected boards not being found on the SPI bus - this can be because the SPI bus does not function correctly for some reason, or because the I2C EEPROM which stores data about which boards are expected does not function correctly.

@tempurpri said in Evok problem getting I/O boards data:

@tomas_knot The incompatibility with Codesys (the one you mention and the port incompatibility) would be an understandeable reason for the problems I have....had I not managed to have a working setup of Codesys for raspberry and evok running in the last month.

Unless the 1-wire incompatibility between the two only becomes problematic with time (I'm not sure how that could be), then that was not the case for me. Just to make it clear Codesys and digital signal readout worked for me ... Modbus acces and the web interface. I needed that functionality only occasionally, so I'm not sure when it stopped working, but it was during the last month. Neither Codesys nor evok were re-installed nor was there any change in their configuration.

I'm trying to find out what happened and especially try to make it work again.

@tomas_knot @tomas_hora I understand that proper codesys integration is coming, but unless it's coming during this week it won't help my application. Unfortunately that's the timeframe I'm looking at, nothing to do with with Unipi itself.

OK, so if codesys 1 wire driver is the suspect, is there a way to check that and maybe disable it within the Codesys editor ?

I was assuming you have a 1Wire UniPi expansion board, which would not work correctly with Codesys. If you do not, it may still be possible to get it running. But first - does the device function correctly with a clean non-Codesys image? If yes then we can confidently say the issue lies with Codesys, and proceed from there.