@jasperjackson said in io.writeport TCP:
io.writeport(conn_handle,adr command[0],10);
Got it... one has to keep calling
io.writeport(conn_handle,adr command[0],10);
until it returns true :)
@jasperjackson said in io.writeport TCP:
io.writeport(conn_handle,adr command[0],10);
Got it... one has to keep calling
io.writeport(conn_handle,adr command[0],10);
until it returns true :)
Hello all!
I'm trying to implement a very simple ASCII tcp protocoll to control some ali-express ethernet relais.
The protocoll is very very easy, no security.
ASCII string: 11 pulls relay 1
ASCII string: 21 releases relay 1
So, this works when using packetsender from my phone, works when using packetsender from my laptop. But it doesn't work using io.writeport from a ST file.
Using wireshark i found out that communication is working, but the packets are not valid (len=0). So i'm doing something wrong.
The code sending the string is as follows:
FUNCTION_BLOCK EthernetRelais
(*
EXTENDS //base type
IMPLEMENTS //interface type list
*)
VAR
connection : string;
conn_handle : io.commhandle;
fsm : int := 0;
command : array[0..10] of byte;
local_state : byte := 0;
initial : bool := 1;
portstatus : int;
timeout : int;
i : int;
(* add local variables here *)
END_VAR
VAR_INPUT
(* add in variables here *)
state : bool;
END_VAR
VAR_OUTPUT
(* add out variables here *)
current_state : bool;
END_VAR
case fsm OF
0:
if state <> local_state or initial THEN
local_state := state;
fsm := 1;
initial := false;
timeout := 1000;
END_IF;
1:
connection := 'tcp:192.168.1.5:6722';
conn_handle := io.openport(connection);
fsm := 2;
2:
portstatus := io.getportstatus(conn_handle);
if portstatus = 0 THEN
fsm := 3;
END_IF;
timeout := timeout -1;
if timeout = 0 THEN
io.closeport(conn_handle);
fsm := 0;
END_IF;
3:
if local_state = 1 THEN
command[0] := 49;
command[1] := 49;
ELSE
command[0] := 50;
command[1] := 49;
END_IF;
io.writeport(conn_handle,adr command[0],10);
io.closeport(conn_handle);
fsm := 0;
ELSE
fsm := 0;
end_case;
(*
METHOD abc //: return type
// method's body
END_METHOD
*)
(*function block body*)
END_FUNCTION_BLOCK
This is the output of wireshark:
192.168.1.5 is my laptop
192.168.1.7 is my unipi
This is the communication of the ST code only. No idea why everything has zero length. And my data is nowhere to be found in the packages.
Any help would be appreciated!
Regards,
Jasper Jackson
Hi All!
A friend of mine accidentally connected his Unipi 1.1 Board with a raspberry pi 3b+ to a 12V adapter. The raspberry shut down after a very short time because it became to hot.
After the incident i've tested the raspberry with one of my own Unipi's and that still worked. Only the Unipi 1.1 board is not detected anymore using i2cdetect. The voltages on the Unipi are still all ok, the LED's on the inputs still work.
I've read that during the first start a firmware is flashed into the unipi.
That process was probably aborted by the shutdown of the raspberry.
Can we check ourselves if that is the case? In other words, can we flash the firmware ourselves using (i.e. a rs232 connection or SPI, i even got a JTAG interface if needed)?
Please let me know!
Regards,
Jasper Jackson
So.. I finally got to the source of the problem. After a lot of measuring en swearing we discovered that under some conditions (rapid temperature change) some sensors kept the data line low to approx. 1.6V rendering the other sensors unable to communicate. It turned out that only a powerreset of the unipi board resolved the problem for some time what pointed me in the direction of the UNIPI board. Wrong! After some googleing i found the following blog:
https://blog.peku33.net/aliexpress-ebay-china-market-fake-ds18b20-sensors/
So, there you go... Lots work to find out that the DS18B20 sensors I got from AliExpress where fake ones and did exactly what was described in the Blog.
I'll order new (genuine) ones soon.
So for everyone experiencing these problems. Check where your sensors came from.
Tanks for the help anyway ;)
Regards,
Jasper Jackson
@jasperjackson said in Vanishing 1-wire sensors:
Hi Thomas!
I didn't find anything yet...
Looking at the cabeling again...
What surprises me by the way is that you sell 1-wire sensors with 10 meters of unshielded cable??
https://www.unipi.technology/1-wire-temperature-sensor-p63
How can that be right?
@tomas_hora
Ok! Thanks for the reply!, i'll look for emc sources, and i'll change the unipi and the raspberry with my other one to rule out hardware failure.
I'll keep you posted if i find anything.
Resetting the driver didn't work.
I read in some other forum that i2cdetect returning all addresses usually means that the SDA of the I2C is bound to ground somehow.
Maybe there lays a problem.
Regards,
Jasper Jackson
@jasperjackson said in Vanishing 1-wire sensors:
Hi Thomas!
Thanks for your reply!When i disconnect the 1-Wire bus and reconnect it, (even when i give the unipi a softreset with no sensors connected before reconnecting the sensors again), the problem will not go away.
It seems different than the problems other users reported. In their cases a hard reset of only the 1-Wire bus solves the problem, thus, putting it on a Relay makes it possible to remotely reset.
In this case a hardreset of the 1-Wire bus does not resolve the problem.
Could it be a problem with the I2C? The kernel driver reports that the DS2482 is not a DS2482. So it seems to me that the problem is I2C related, or the DS2484 hangs for some reason.
Can I Analyse this somehow? I don't understand the i2cdetect command very well, maybe you can point me in the right direction here.I Have 2 Unipies by the way, one with shitty unshielded telephone cables through my whole house for the 1-Wire (Works flawlessly) and the one with CAT-5 FTP, (causing troubles).
The Unipi is remotely accessible through SSH, so i can try almost everything remotely.
Regards,
Jasper Jackson
Did some more research, this is the output of the failing unipi
root@unipi:~# i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
30: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
50: UU 51 52 53 54 55 56 UU 58 59 5a 5b 5c 5d 5e 5f
60: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
70: 70 71 72 73 74 75 76 77
And this is the output of my functioning unipi
root@unipi:~# i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- --
20: 20 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: UU -- -- -- -- -- -- UU -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- UU
70: -- -- -- -- -- -- -- --
I have a hard time imagining that this has something to do with my 1-Wire setup.
Hi Thomas!
Thanks for your reply!
When i disconnect the 1-Wire bus and reconnect it, (even when i give the unipi a softreset with no sensors connected before reconnecting the sensors again), the problem will not go away.
It seems different than the problems other users reported. In their cases a hard reset of only the 1-Wire bus solves the problem, thus, putting it on a Relay makes it possible to remotely reset.
In this case a hardreset of the 1-Wire bus does not resolve the problem.
Could it be a problem with the I2C? The kernel driver reports that the DS2482 is not a DS2482. So it seems to me that the problem is I2C related, or the DS2484 hangs for some reason.
Can I Analyse this somehow? I don't understand the i2cdetect command very well, maybe you can point me in the right direction here.
I Have 2 Unipies by the way, one with shitty unshielded telephone cables through my whole house for the 1-Wire (Works flawlessly) and the one with CAT-5 FTP, (causing troubles).
The Unipi is remotely accessible through SSH, so i can try almost everything remotely.
Regards,
Jasper Jackson
@jasperjackson said in Vanishing 1-wire sensors:
@tomas_hora looks like disabeling the rtc kernel module fixed the problem. Things are still running perfectly :)
Too early....
unfortunatly i got another problem now after 3 days of operation. The problem is not the one wire sensors. I resetted the 1-Wirebus by disconnecting all the sensors. I then did a softreset of the raspberry/unipi, no sensors where found. It turns out there is a problem with the DS2482.
[ 273.108220] Driver for 1-wire Dallas network protocol.
[ 279.979503] ds2482 1-0018: DS2482 reset status 0x00 - not a DS2482
Only a hardreset of the unipi resolves the problem. I'm running out of options here.. any help would be appreciated. I'll mount the rtc battery for now and see if the problems will go away. The main problem is that the unipi is controlling my heating in Austria and I live in holland. I'll probably need a second unipi to reset the main one :(.
Regards,
Jasper