Turned off commenting on the OVMS v3 User Guide
I’ve had to turn off commenting on the OVMS v3 user guide. Too many people with just no idea what they are doing messing around. If any developers would like to comment on, or help edit/expand, that guide, send me your email address and I’ll add you with specific access rights. Regards, Mark
Am 16.04.2018 um 04:15 schrieb Mark Webb-Johnson:
I’ve had to turn off commenting on the OVMS v3 user guide. Too many people with just no idea what they are doing messing around.
Indeed. Thanks. I'll ask for qualified help on the forum. On the positive side: we can already see now how the system performs for normal users. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
On the positive side: we can already see now how the system performs for normal users.
It was an ‘interesting’ weekend. Thanks for your help with the support. My server is now showing 14 v3.x modules connected (2 of which are mine): 6 running 3.1.001/factory/main 4 running 3.1.003/ota_0/main 1 running 3.1.003-38-g435f516/factory/main 1 running 3.1.003-41-gc299c84-dirty/ota_0/ro1 2 running 3.1.003-48-g7cfbc35/ota_1/edge We had about 6 people ask for help, and 14 got connected in the end. I think all but one that asked for help got connected ok. For experienced users, that support call ratio is way too high - mostly lack of documentation and issues with wifi settings being incorrectly set then unable to get back in. Presumably you also have some connected to your server? I’m just looking for ‘build idf’ in the version string in ‘rx msg F’. How many did you get? The 3.1.003/ota_0/main is the latest main firmware. But the 6x running 3.1.001/factory/main haven’t updated firmware. That is not good. I think we should be able to release 3.1.004 ota tomorrow. I’ll then send out an eMail to all purchasers reminding them to (a) update, (b) use the help support system, and (c) some reminders (a faq based on what we’ve seen the past few days). Anything else to put in that eMail?
I'll ask for qualified help on the forum.
I think expanding on the basics (in particular for windows) would be helpful. How to get a USB console connection. How to update firmware. How to diagnose network/modem issues (simcom status, network status, wifi status). etc. Perhaps a command-line USB console installation guide (to supplement the web admin based one)? We have about a month before the next batch will start to arrive, and that will be for less technically capable people. Regards, Mark
On 16 Apr 2018, at 6:48 PM, Michael Balzer <dexter@expeedo.de> wrote:
Am 16.04.2018 um 04:15 schrieb Mark Webb-Johnson:
I’ve had to turn off commenting on the OVMS v3 user guide. Too many people with just no idea what they are doing messing around.
Indeed. Thanks. I'll ask for qualified help on the forum.
On the positive side: we can already see now how the system performs for normal users.
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Am 16.04.2018 um 14:59 schrieb Mark Webb-Johnson:
My server is now showing 14 v3.x modules connected (2 of which are mine):
* 6 running 3.1.001/factory/main * 4 running 3.1.003/ota_0/main * 1 running 3.1.003-38-g435f516/factory/main * 1 running 3.1.003-41-gc299c84-dirty/ota_0/ro1 * 2 running 3.1.003-48-g7cfbc35/ota_1/edge
We had about 6 people ask for help, and 14 got connected in the end. I think all but one that asked for help got connected ok. For experienced users, that support call ratio is way too high - mostly lack of documentation and issues with wifi settings being incorrectly set then unable to get back in.
Presumably you also have some connected to your server? I’m just looking for ‘build idf’ in the version string in ‘rx msg F’. How many did you get?
This is the current status over here: SELECT LEFT(m_msg, INSTR(m_msg,'/')-1) AS version, COUNT(*) FROM ovms_carmessages WHERE m_code='F' AND m_msg LIKE '%build idf%' GROUP BY version WITH ROLLUP version count(*) 3.1.001 1 3.1.001-19-g02ae9c4 1 3.1.003 4 3.1.003-14-gad46fb2 1 3.1.003-23-ga2804b8 1 3.1.003-38-g435f516 1 3.1.003-41-gc299c84 1 3.1.003-44-g627d21e-dirty 1 3.1.003-45-g9fabbea 3 14 Two of those are mine, and I think some more are Toms (?).
The 3.1.003/ota_0/main is the latest main firmware. But the 6x running 3.1.001/factory/main haven’t updated firmware. That is not good.
I think we should be able to release 3.1.004 ota tomorrow. I’ll then send out an eMail to all purchasers reminding them to (a) update, (b) use the help support system, and (c) some reminders (a faq based on what we’ve seen the past few days). Anything else to put in that eMail?
A reminder to include more detail in bug reports / support requests. The request for qualified help on the user guide. Maybe my EU firmware mirror, but I'd like to make the directory structure fit to the new ota config options first -- I'll tell you. Regards, Michael
Regards, Mark
On 16 Apr 2018, at 6:48 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Am 16.04.2018 um 04:15 schrieb Mark Webb-Johnson:
I’ve had to turn off commenting on the OVMS v3 user guide. Too many people with just no idea what they are doing messing around.
Indeed. Thanks. I'll ask for qualified help on the forum.
On the positive side: we can already see now how the system performs for normal users.
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
On Mon, Apr 16, 2018 at 08:59:58PM +0800, Mark Webb-Johnson wrote:
My server is now showing 14 v3.x modules connected (2 of which are mine): ... 1 running 3.1.003-41-gc299c84-dirty/ota_0/ro1
That would be me. As a long-time follower of the project, but first-time user of an actual OVMS device, I would say my "getting started" experience was very good; mostly plusses, with few minuses (and some of those seemed to go away later without my intervention): + OVMS unit plugged in to USB power. - No obvious power/status LED (I've since spotted it inside). + Connected to OVMS access point using android phone. - Tried to visit 192.168.4.1 in phone's web browser (Firefox 55.0.2); it seemed to connect, but would only display a blank page. + Connected OK with 'ssh admin@192.168.4.1' + Entered 'enable' and poked around with some wifi/network commands. - Couldn't figure out how to set up wifi client ssid and password. - google docs mentions 'config list wifi.ssid' but not how you add new ones. - Tried 'wifi scan', which cut off my ssh connection. Rebooted. + Connected to OVMS access point again, this time with a debian laptop. + Successfully visited 192.168.4.1 in web browser (Firefox 52.3.0). + Changed password as prompted. + Added wifi client ssid and password. - Took a while for me to find the option 'Autostart - Wifi mode:' + Set that to 'Access point + Client'; Save & reboot. + OVMS got an address as a wifi client in my network. + Successfully visited web page on new IP address. - 'ssh admin@NEWIP' connects, but then immediately closes the connection. + Plugged module in to car (Nissan Leaf 2016). + Configured vehicle type etc. + Battery, range, odometer, temperature status updates. + Configured OVMSv2 server at api.openvehicles.com. + Module's web status says 'State: Connected'. - Not sure how to tell if it's working at the server end. + Download and install android app. - Server defaults to tmc.openvehicles.com (not api....) - Not sure what to put for SMS/module password. - Control - FEATURES, PARAMETERS both get stuck waiting for data. (they started working some time later). + Live values start showing up! + Set up account with https://hologram.io/ - google doc doesn't give URL - Tried 'metric list m.net.mdm.iccid', but that just printed 'm.net.mdm.iccid' (it started working some time later). + Activated SIM at https://dashboard.hologram.io/ + ota update to 3.1.003 worked flawlessly Since then, I got a development environment set up with remarkably little trouble, and I've been adding some new metrics for the Nissan Leaf: * ms_v_bat_soh from 0x5b3[1] * ms_v_charge_temp from 0x54f[0] (this is actually inside temp) * ms_v_door_fl etc. from 0x60d[0] * ms_v_env_gear from 0x421[0] * ms_v_env_handbrake from 0x5c5[0] (was faked by vehicle_nissanleaf_car_on) * ms_v_env_headlights from 0x60d[0,1] * ms_v_env_on from 0x60d[1] (was faked by vehicle_nissanleaf_car_on) ...but continue to fake ms_v_env_awake by CAN activity of 0x284 * ms_v_env_locked from 0x60d[2] * ms_v_inv_temp from 0x510[7] * ms_v_tpms_fl_p etc. from 0x385[2..5] These all seem to be working nicely (at least, on my UK MY2015). I have a few questions: I would like to record the temperature inside the car, but I couldn't see an appropriate metric (I've stuck it on ms_v_charge_temp for now). Is there a better place for it? What is the intent of ms_v_env_on? It was previously set true when certain CAN traffic was present and false after a period of inactivity. I now set it to true when the car is in state "ready to drive". A similar question goes for ms_v_env_awake. I've left this doing the CAN activity detection, which means it changes for minor things like detecting a key-fob. What is the process for contributing changes? I am currently doing my local work on the master branch cloned from github. Even after upgrading the firmware to the latest from git, I still have the problem with ssh connecting but then immediately dropping. Is there some debug option I should turn on to find out why?
On Thu, 19 Apr 2018, Robin O'Leary wrote:
That would be me. As a long-time follower of the project, but first-time user of an actual OVMS device, I would say my "getting started" experience was very good; mostly plusses, with few minuses (and some of those seemed to go away later without my intervention): [snip] + Connected OK with 'ssh admin@192.168.4.1' [snip] - 'ssh admin@NEWIP' connects, but then immediately closes the connection.
As the implementer of the ssh functionality, I'd like to know more about what happened here. Does ssh still immediately close the connection? If so, can you try 'ssh -v admin@NEWIP' and report back the output? On the v3.0 hardware with limited RAM, the connection closes immediately because the DH handshake fails due to a memory allocation failure. But with v3.1 hardware there is plenty of RAM. -- Steve
On Thu, Apr 19, 2018 at 11:23:15AM -0700, Stephen Casner wrote:
On Thu, 19 Apr 2018, Robin O'Leary wrote: [snip]
- 'ssh admin@NEWIP' connects, but then immediately closes the connection.
As the implementer of the ssh functionality, I'd like to know more about what happened here. Does ssh still immediately close the connection? If so, can you try 'ssh -v admin@NEWIP' and report back the output?
Yes it does, but I've now tried from a few other hosts running different OS versions with mixed results: fail OpenSSH_7.7p1 Debian-2, OpenSSL 1.0.2o 27 Mar 2018 OK OpenSSH_7.4p1 Raspbian-10+deb9u3, OpenSSL 1.0.2l 25 May 2017 OK OpenSSH_7.4p1 Debian-10+deb9u2, OpenSSL 1.0.2l 25 May 2017 OK OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t 3 May 2016 hang OpenSSH_5.9p1 Debian-5, OpenSSL 1.0.1b 26 Apr 2012
On the v3.0 hardware with limited RAM, the connection closes immediately because the DH handshake fails due to a memory allocation failure. But with v3.1 hardware there is plenty of RAM.
Is there some server-side debug I can turn on? debian 10 (buster) connects but immediately closes: $ ssh -v admin@chevaline OpenSSH_7.7p1 Debian-2, OpenSSL 1.0.2o 27 Mar 2018 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to chevaline [...] port 22. debug1: Connection established. debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_rsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_ed25519-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_xmss type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_xmss-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_7.7p1 Debian-2 debug1: Remote protocol version 2.0, remote software version wolfSSHv1.1.0 debug1: no match: wolfSSHv1.1.0 debug1: Authenticating to chevaline:22 as 'admin' debug1: SSH2_MSG_KEXINIT sent Connection closed by chevaline port 22 The relevant section of /etc/ssh/ssh_config says: Host * SendEnv LANG LC_* HashKnownHosts yes GSSAPIAuthentication yes Raspbian 9 (stretch) works OK: $ ssh -v admin@chevaline OpenSSH_7.4p1 Raspbian-10+deb9u3, OpenSSL 1.0.2l 25 May 2017 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to chevaline [...] port 22. debug1: Connection established. debug1: identity file /home/robin/.ssh/id_rsa type 1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Raspbian-10+deb9u3 debug1: Remote protocol version 2.0, remote software version wolfSSHv1.1.0 debug1: no match: wolfSSHv1.1.0 debug1: Authenticating to chevaline:22 as 'admin' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: diffie-hellman-group-exchange-sha256 debug1: kex: host key algorithm: ssh-rsa debug1: kex: server->client cipher: aes128-cbc MAC: hmac-sha2-256 compression: none debug1: kex: client->server cipher: aes128-cbc MAC: hmac-sha2-256 compression: none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<8192<8192) sent debug1: got SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: got SSH2_MSG_KEX_DH_GEX_REPLY debug1: Server host key: ssh-rsa SHA256:2bW5kEnFXZ+ORn3PB00qJa7jRsKkW8zSTyXTuECvVfo The authenticity of host 'chevaline (...)' can't be established. RSA key fingerprint is SHA256:2bW5kEnFXZ+ORn3PB00qJa7jRsKkW8zSTyXTuECvVfo. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'chevaline' (RSA) to the list of known hosts. debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/robin/.ssh/id_rsa debug1: Authentications that can continue: publickey,password debug1: Trying private key: /home/robin/.ssh/id_dsa debug1: Trying private key: /home/robin/.ssh/id_ecdsa debug1: Trying private key: /home/robin/.ssh/id_ed25519 debug1: Next authentication method: password admin@chevaline's password: ... debian 9 (stretch) works OK: $ ssh -v admin@chevaline OpenSSH_7.4p1 Debian-10+deb9u2, OpenSSL 1.0.2l 25 May 2017 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to chevaline [...] port 22. debug1: Connection established. debug1: identity file /home/robin/.ssh/id_rsa type 1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u2 debug1: Remote protocol version 2.0, remote software version wolfSSHv1.1.0 debug1: no match: wolfSSHv1.1.0 debug1: Authenticating to chevaline:22 as 'admin' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: diffie-hellman-group-exchange-sha256 debug1: kex: host key algorithm: ssh-rsa debug1: kex: server->client cipher: aes128-cbc MAC: hmac-sha2-256 compression: none debug1: kex: client->server cipher: aes128-cbc MAC: hmac-sha2-256 compression: none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<8192<8192) sent debug1: got SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: got SSH2_MSG_KEX_DH_GEX_REPLY debug1: Server host key: ssh-rsa SHA256:2bW5kEnFXZ+ORn3PB00qJa7jRsKkW8zSTyXTuECvVfo debug1: Host 'chevaline' is known and matches the RSA host key. debug1: Found key in /home/robin/.ssh/known_hosts:45 debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/robin/.ssh/id_rsa debug1: Authentications that can continue: publickey,password debug1: Trying private key: /home/robin/.ssh/id_dsa debug1: Trying private key: /home/robin/.ssh/id_ecdsa debug1: Trying private key: /home/robin/.ssh/id_ed25519 debug1: Next authentication method: password admin@chevaline's password: debug1: Authentication succeeded (password). ... debian 8 (jessie) works OK: $ ssh -v admin@chevaline OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t 3 May 2016 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to chevaline [...] port 22. debug1: Connection established. debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_rsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3 debug1: Remote protocol version 2.0, remote software version wolfSSHv1.1.0 debug1: no match: wolfSSHv1.1.0 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-sha2-256 none debug1: kex: client->server aes128-cbc hmac-sha2-256 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<8192<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Server host key: RSA 9b:91:8b:85:00:77:7e:87:a9:5d:60:f6:2a:83:dd:c6 The authenticity of host 'chevaline (...)' can't be established. RSA key fingerprint is 9b:91:8b:85:00:77:7e:87:a9:5d:60:f6:2a:83:dd:c6. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'chevaline' (RSA) to the list of known hosts. debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Trying private key: /home/robin/.ssh/id_rsa debug1: Trying private key: /home/robin/.ssh/id_dsa debug1: Trying private key: /home/robin/.ssh/id_ecdsa debug1: Trying private key: /home/robin/.ssh/id_ed25519 debug1: Next authentication method: password admin@chevaline's password: ... debian 6 (squeeze) fails in a different way; it just hangs: $ ssh -v admin@chevaline OpenSSH_5.9p1 Debian-5, OpenSSL 1.0.1b 26 Apr 2012 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to chevaline [...] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /home/robin/.ssh/id_rsa type -1 debug1: identity file /home/robin/.ssh/id_rsa-cert type -1 debug1: identity file /home/robin/.ssh/id_dsa type -1 debug1: identity file /home/robin/.ssh/id_dsa-cert type -1 debug1: identity file /home/robin/.ssh/id_ecdsa type -1 debug1: identity file /home/robin/.ssh/id_ecdsa-cert type -1
Robin, Thanks for the debug outputs. For the buster case where the connection immediately closes, there must be something about the DH handshake that the server can't handle, but the client-side debug output doesn't indicate what that might be. You can enable some logging by the server on the USB/async console with the command: log level debug wolfssh This causes a lot of blathering that won't be useful, but there may be a useful hint near the end of it. Maybe that will tell us something for the squeeze case as well. You can install your RSA public key as follows, associated with your normal username (robin, I assume) so you don't have to type "admin@". Quoting from an earlier message on the topic: - RSA public keys may be stored under param ssh.keys with the instance being the associated username. The key format is as generated on a Linux or Mac system by the command "ssh-keygen -b 2048 -t rsa". This could be a key you already have or a new one made for this purpose. Only the one long string of the base64-encoded key should be stored, not including the "ssh-rsa" at the beginning or the user ID at the end. The key is stored with a command like this: config set ssh.keys robin AAAAB3NzaC1yc2EAAAADAQAB...C6p5jcbf4NCnX -- Steve On Thu, 19 Apr 2018, Robin O'Leary wrote:
On Thu, Apr 19, 2018 at 11:23:15AM -0700, Stephen Casner wrote:
On Thu, 19 Apr 2018, Robin O'Leary wrote: [snip]
- 'ssh admin@NEWIP' connects, but then immediately closes the connection.
As the implementer of the ssh functionality, I'd like to know more about what happened here. Does ssh still immediately close the connection? If so, can you try 'ssh -v admin@NEWIP' and report back the output?
Yes it does, but I've now tried from a few other hosts running different OS versions with mixed results:
fail OpenSSH_7.7p1 Debian-2, OpenSSL 1.0.2o 27 Mar 2018 OK OpenSSH_7.4p1 Raspbian-10+deb9u3, OpenSSL 1.0.2l 25 May 2017 OK OpenSSH_7.4p1 Debian-10+deb9u2, OpenSSL 1.0.2l 25 May 2017 OK OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t 3 May 2016 hang OpenSSH_5.9p1 Debian-5, OpenSSL 1.0.1b 26 Apr 2012
On the v3.0 hardware with limited RAM, the connection closes immediately because the DH handshake fails due to a memory allocation failure. But with v3.1 hardware there is plenty of RAM.
Is there some server-side debug I can turn on?
debian 10 (buster) connects but immediately closes:
$ ssh -v admin@chevaline OpenSSH_7.7p1 Debian-2, OpenSSL 1.0.2o 27 Mar 2018 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to chevaline [...] port 22. debug1: Connection established. debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_rsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_ed25519-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_xmss type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_xmss-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_7.7p1 Debian-2 debug1: Remote protocol version 2.0, remote software version wolfSSHv1.1.0 debug1: no match: wolfSSHv1.1.0 debug1: Authenticating to chevaline:22 as 'admin' debug1: SSH2_MSG_KEXINIT sent Connection closed by chevaline port 22
The relevant section of /etc/ssh/ssh_config says:
Host * SendEnv LANG LC_* HashKnownHosts yes GSSAPIAuthentication yes
Raspbian 9 (stretch) works OK:
$ ssh -v admin@chevaline OpenSSH_7.4p1 Raspbian-10+deb9u3, OpenSSL 1.0.2l 25 May 2017 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to chevaline [...] port 22. debug1: Connection established. debug1: identity file /home/robin/.ssh/id_rsa type 1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Raspbian-10+deb9u3 debug1: Remote protocol version 2.0, remote software version wolfSSHv1.1.0 debug1: no match: wolfSSHv1.1.0 debug1: Authenticating to chevaline:22 as 'admin' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: diffie-hellman-group-exchange-sha256 debug1: kex: host key algorithm: ssh-rsa debug1: kex: server->client cipher: aes128-cbc MAC: hmac-sha2-256 compression: none debug1: kex: client->server cipher: aes128-cbc MAC: hmac-sha2-256 compression: none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<8192<8192) sent debug1: got SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: got SSH2_MSG_KEX_DH_GEX_REPLY debug1: Server host key: ssh-rsa SHA256:2bW5kEnFXZ+ORn3PB00qJa7jRsKkW8zSTyXTuECvVfo The authenticity of host 'chevaline (...)' can't be established. RSA key fingerprint is SHA256:2bW5kEnFXZ+ORn3PB00qJa7jRsKkW8zSTyXTuECvVfo. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'chevaline' (RSA) to the list of known hosts. debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/robin/.ssh/id_rsa debug1: Authentications that can continue: publickey,password debug1: Trying private key: /home/robin/.ssh/id_dsa debug1: Trying private key: /home/robin/.ssh/id_ecdsa debug1: Trying private key: /home/robin/.ssh/id_ed25519 debug1: Next authentication method: password admin@chevaline's password: ...
debian 9 (stretch) works OK:
$ ssh -v admin@chevaline OpenSSH_7.4p1 Debian-10+deb9u2, OpenSSL 1.0.2l 25 May 2017 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to chevaline [...] port 22. debug1: Connection established. debug1: identity file /home/robin/.ssh/id_rsa type 1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u2 debug1: Remote protocol version 2.0, remote software version wolfSSHv1.1.0 debug1: no match: wolfSSHv1.1.0 debug1: Authenticating to chevaline:22 as 'admin' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: diffie-hellman-group-exchange-sha256 debug1: kex: host key algorithm: ssh-rsa debug1: kex: server->client cipher: aes128-cbc MAC: hmac-sha2-256 compression: none debug1: kex: client->server cipher: aes128-cbc MAC: hmac-sha2-256 compression: none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<8192<8192) sent debug1: got SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: got SSH2_MSG_KEX_DH_GEX_REPLY debug1: Server host key: ssh-rsa SHA256:2bW5kEnFXZ+ORn3PB00qJa7jRsKkW8zSTyXTuECvVfo debug1: Host 'chevaline' is known and matches the RSA host key. debug1: Found key in /home/robin/.ssh/known_hosts:45 debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/robin/.ssh/id_rsa debug1: Authentications that can continue: publickey,password debug1: Trying private key: /home/robin/.ssh/id_dsa debug1: Trying private key: /home/robin/.ssh/id_ecdsa debug1: Trying private key: /home/robin/.ssh/id_ed25519 debug1: Next authentication method: password admin@chevaline's password: debug1: Authentication succeeded (password). ...
debian 8 (jessie) works OK:
$ ssh -v admin@chevaline OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t 3 May 2016 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to chevaline [...] port 22. debug1: Connection established. debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_rsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/robin/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3 debug1: Remote protocol version 2.0, remote software version wolfSSHv1.1.0 debug1: no match: wolfSSHv1.1.0 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-sha2-256 none debug1: kex: client->server aes128-cbc hmac-sha2-256 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<8192<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Server host key: RSA 9b:91:8b:85:00:77:7e:87:a9:5d:60:f6:2a:83:dd:c6 The authenticity of host 'chevaline (...)' can't be established. RSA key fingerprint is 9b:91:8b:85:00:77:7e:87:a9:5d:60:f6:2a:83:dd:c6. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'chevaline' (RSA) to the list of known hosts. debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Trying private key: /home/robin/.ssh/id_rsa debug1: Trying private key: /home/robin/.ssh/id_dsa debug1: Trying private key: /home/robin/.ssh/id_ecdsa debug1: Trying private key: /home/robin/.ssh/id_ed25519 debug1: Next authentication method: password admin@chevaline's password: ...
debian 6 (squeeze) fails in a different way; it just hangs:
$ ssh -v admin@chevaline OpenSSH_5.9p1 Debian-5, OpenSSL 1.0.1b 26 Apr 2012 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to chevaline [...] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /home/robin/.ssh/id_rsa type -1 debug1: identity file /home/robin/.ssh/id_rsa-cert type -1 debug1: identity file /home/robin/.ssh/id_dsa type -1 debug1: identity file /home/robin/.ssh/id_dsa-cert type -1 debug1: identity file /home/robin/.ssh/id_ecdsa type -1 debug1: identity file /home/robin/.ssh/id_ecdsa-cert type -1
On Thu, Apr 19, 2018 at 03:03:20PM -0700, Stephen Casner wrote:
Thanks for the debug outputs. For the buster case where the connection immediately closes, there must be something about the DH handshake that the server can't handle, but the client-side debug output doesn't indicate what that might be. You can enable some logging by the server on the USB/async console with the command:
log level debug wolfssh
This causes a lot of blathering that won't be useful, but there may be a useful hint near the end of it. Maybe that will tell us something for the squeeze case as well.
The log output was very brief: E (43385740) ssh: Error in reception: -20 I tried a few more times, and got: E (43507430) ssh: Error in reception: -20 E (43516610) ssh: Error in reception: -20 E (43647420) ssh: Error in reception: -20
You can install your RSA public key as follows, ...
Will do, thanks.
On Thu, 19 Apr 2018, Robin O'Leary wrote:
On Thu, Apr 19, 2018 at 03:03:20PM -0700, Stephen Casner wrote:
Thanks for the debug outputs. For the buster case where the connection immediately closes, there must be something about the DH handshake that the server can't handle, but the client-side debug output doesn't indicate what that might be. You can enable some logging by the server on the USB/async console with the command:
log level debug wolfssh
This causes a lot of blathering that won't be useful, but there may be a useful hint near the end of it. Maybe that will tell us something for the squeeze case as well.
The log output was very brief:
E (43385740) ssh: Error in reception: -20
Oops, I forgot, the code to generate the wolfssh log messages is not compiled in by default, so an edit to components/wolfssh/component.mk is required for that log output from the WolfSSH library to be generated. The message we see is output by my code reporting an error code from the library. If logging in wolfssh had been enabled, we would have seen one of the following: "Unable to negotiate KEX Algo" "Unable to negotiate Server Host Key Algo" "Unable to negotiate Encryption Algo Client to Server" "Unable to negotiate Encryption Algo Server to Client" "Unable to negotiate MAC Algo Client to Server" "Unable to negotiate MAC Algo Server to Client" "Unable to negotiate Compression Algo Client to Server" "Unable to negotiate Compression Algo Server to Client" "Public Key's type does not match public key type" "Signature's type does not match public key type" pkTypeId != ID_SSH_RSA That covers a lot of territory. If you would like to dig further, you can uncomment this line in components/wolfssh/component.mk and compile again (it may be necessary to make clean first): #CFLAGS += -DDEBUG_WOLFSSH Then try again with the "log level debug wolfssh" and we should get one of those messages. -- Steve
On Thu, Apr 19, 2018 at 04:39:09PM -0700, Stephen Casner wrote:
On Thu, 19 Apr 2018, Robin O'Leary wrote:
The log output was very brief:
E (43385740) ssh: Error in reception: -20
... If you would like to dig further, you can uncomment this line in components/wolfssh/component.mk and compile again (it may be necessary to make clean first):
#CFLAGS += -DDEBUG_WOLFSSH
OK, so that started me on quite an adventure in to compiler errors and git submodules, but the upshot is that wolfssh only supports cipher aes128-cbc and openssh now has this disabled by default. From http://www.openssh.com/txt/release-6.7: Changes since OpenSSH 6.6 ========================= Potentially-incompatible changes * sshd(8): The default set of ciphers and MACs has been altered to remove unsafe algorithms. In particular, CBC ciphers and arcfour* are disabled by default. ... At least for now, aes128-cbc is still supported, so I can do: ssh -c aes128-cbc ... or more permanently in ~/.ssh/config: Host chevaline Ciphers +aes128-cbc Thanks for your help pursuing this.
On Fri, 20 Apr 2018, Robin O'Leary wrote:
OK, so that started me on quite an adventure in to compiler errors and git submodules,
Sorry, did my commit of an update to mongoose trip you up? Perhaps I should configure in the debug code for wolfssh and wolfssl by default so the extra logging can be enabled whenever it is needed. Mark, that would consume a bit more code space, would that be a problem?
but the upshot is that wolfssh only supports cipher aes128-cbc and openssh now has this disabled by default.
WolfSSH also supports aes128-ctr and aes128-gcm, but I was warned that the latter is much more expensive in speed and memory, so I excluded it from the configuration for compilation. -- Steve
On Fri, Apr 20, 2018 at 11:39:18PM -0700, Stephen Casner wrote:
On Fri, 20 Apr 2018, Robin O'Leary wrote:
OK, so that started me on quite an adventure in to compiler errors and git submodules, Sorry, did my commit of an update to mongoose trip you up?
That was just one of several things, but one of the easily resolved ones! Much more annoying was a mysterious error about an undefined reference to "_impure_ptr", since that appears nowhere in the code. I tracked it down to the fprintf in wolfssh/src/log.c; I still don't understand why, but I just commented it out, as ovms uses logFunction instead.
Perhaps I should configure in the debug code for wolfssh and wolfssl by default so the extra logging can be enabled whenever it is needed.
Adding more calls to GetErrorString() in ssh.c is probably more helpful. It would be good to have a menu config option to define DEBUG_WOLFSSH.
WolfSSH also supports aes128-ctr and aes128-gcm, but I was warned that the latter is much more expensive in speed and memory, so I excluded it from the configuration for compilation.
I think there is full support for aes128-ctr in wolfssl/wolfcrypt, but the places where it needs to be in wolfssh seem to be mostly missing. I had a go at adding it, but I haven't got it working. It does connect, but auth always fails. I haven't had chance to figure out why yet.
On Thu, 26 Apr 2018, Robin O'Leary wrote:
On Fri, Apr 20, 2018 at 11:39:18PM -0700, Stephen Casner wrote:
On Fri, 20 Apr 2018, Robin O'Leary wrote:
OK, so that started me on quite an adventure in to compiler errors and git submodules, Sorry, did my commit of an update to mongoose trip you up?
That was just one of several things, but one of the easily resolved ones! Much more annoying was a mysterious error about an undefined reference to "_impure_ptr", since that appears nowhere in the code. I tracked it down to the fprintf in wolfssh/src/log.c; I still don't understand why, but I just commented it out, as ovms uses logFunction instead.
Oh, I do remember hitting that one myself and having to use Google for help. I think I hit that when I tried to add a printf statement of my own, so maybe if I saw it when enabling DEBUG_WOLFSSH I used the same workaround that you did. I had not remembered that problem when suggesting that you try DEBUG_WOLFSSH. Sorry.
Perhaps I should configure in the debug code for wolfssh and wolfssl by default so the extra logging can be enabled whenever it is needed.
Adding more calls to GetErrorString() in ssh.c is probably more helpful.
That is done, but there is only one error code that is returned for any cipher, MAC or key mismatch, so DEBUG_WOLFSSH is still required to figure out which one.
It would be good to have a menu config option to define DEBUG_WOLFSSH.
I think the only penalty for enabling it always is an increase in code size, ssuming the "_impure_ptr" is fixed in some way. I asked Mark if that would be reasonable to enable always.
WolfSSH also supports aes128-ctr and aes128-gcm, but I was warned that the latter is much more expensive in speed and memory, so I excluded it from the configuration for compilation.
I think there is full support for aes128-ctr in wolfssl/wolfcrypt, but the places where it needs to be in wolfssh seem to be mostly missing. I had a go at adding it, but I haven't got it working. It does connect, but auth always fails. I haven't had chance to figure out why yet.
wolfssh/src/internal.c does reference AES128_CTR in a few places, but I'm not sure what actions are required. I started with WolfSSH 1.1.0 when doing the integration into OVMS. There is a 1.2.0 release out now (on github at wolfSSL/wolfssh), and a 1.3.0 release pending that will include Wolf's integration of my SCP additions back into their code base. -- Steve
It would be good to have a menu config option to define DEBUG_WOLFSSH.
I think the only penalty for enabling it always is an increase in code size, ssuming the "_impure_ptr" is fixed in some way. I asked Mark if that would be reasonable to enable always.
I guess it depends on how much bigger. Debugging the internals of wolfssh is seemingly a rare occurence? Perhaps a menuconfig option (in Components / OVMS / Developer Options) would make sense? Regards, Mark.
On 27 Apr 2018, at 1:16 PM, Stephen Casner <casner@acm.org> wrote:
On Thu, 26 Apr 2018, Robin O'Leary wrote:
On Fri, Apr 20, 2018 at 11:39:18PM -0700, Stephen Casner wrote:
On Fri, 20 Apr 2018, Robin O'Leary wrote:
OK, so that started me on quite an adventure in to compiler errors and git submodules, Sorry, did my commit of an update to mongoose trip you up?
That was just one of several things, but one of the easily resolved ones! Much more annoying was a mysterious error about an undefined reference to "_impure_ptr", since that appears nowhere in the code. I tracked it down to the fprintf in wolfssh/src/log.c; I still don't understand why, but I just commented it out, as ovms uses logFunction instead.
Oh, I do remember hitting that one myself and having to use Google for help. I think I hit that when I tried to add a printf statement of my own, so maybe if I saw it when enabling DEBUG_WOLFSSH I used the same workaround that you did. I had not remembered that problem when suggesting that you try DEBUG_WOLFSSH. Sorry.
Perhaps I should configure in the debug code for wolfssh and wolfssl by default so the extra logging can be enabled whenever it is needed.
Adding more calls to GetErrorString() in ssh.c is probably more helpful.
That is done, but there is only one error code that is returned for any cipher, MAC or key mismatch, so DEBUG_WOLFSSH is still required to figure out which one.
It would be good to have a menu config option to define DEBUG_WOLFSSH.
I think the only penalty for enabling it always is an increase in code size, ssuming the "_impure_ptr" is fixed in some way. I asked Mark if that would be reasonable to enable always.
WolfSSH also supports aes128-ctr and aes128-gcm, but I was warned that the latter is much more expensive in speed and memory, so I excluded it from the configuration for compilation.
I think there is full support for aes128-ctr in wolfssl/wolfcrypt, but the places where it needs to be in wolfssh seem to be mostly missing. I had a go at adding it, but I haven't got it working. It does connect, but auth always fails. I haven't had chance to figure out why yet.
wolfssh/src/internal.c does reference AES128_CTR in a few places, but I'm not sure what actions are required.
I started with WolfSSH 1.1.0 when doing the integration into OVMS. There is a 1.2.0 release out now (on github at wolfSSL/wolfssh), and a 1.3.0 release pending that will include Wolf's integration of my SCP additions back into their code base.
-- Steve _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
… or have it depend on “Include the GPL licensed WOLFSSH and WOLFSSL” and come up as an option under there when enabled. Regards, Mark.
On 27 Apr 2018, at 1:27 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
It would be good to have a menu config option to define DEBUG_WOLFSSH.
I think the only penalty for enabling it always is an increase in code size, ssuming the "_impure_ptr" is fixed in some way. I asked Mark if that would be reasonable to enable always.
I guess it depends on how much bigger. Debugging the internals of wolfssh is seemingly a rare occurence? Perhaps a menuconfig option (in Components / OVMS / Developer Options) would make sense?
Regards, Mark.
On 27 Apr 2018, at 1:16 PM, Stephen Casner <casner@acm.org <mailto:casner@acm.org>> wrote:
On Thu, 26 Apr 2018, Robin O'Leary wrote:
On Fri, Apr 20, 2018 at 11:39:18PM -0700, Stephen Casner wrote:
On Fri, 20 Apr 2018, Robin O'Leary wrote:
OK, so that started me on quite an adventure in to compiler errors and git submodules, Sorry, did my commit of an update to mongoose trip you up?
That was just one of several things, but one of the easily resolved ones! Much more annoying was a mysterious error about an undefined reference to "_impure_ptr", since that appears nowhere in the code. I tracked it down to the fprintf in wolfssh/src/log.c; I still don't understand why, but I just commented it out, as ovms uses logFunction instead.
Oh, I do remember hitting that one myself and having to use Google for help. I think I hit that when I tried to add a printf statement of my own, so maybe if I saw it when enabling DEBUG_WOLFSSH I used the same workaround that you did. I had not remembered that problem when suggesting that you try DEBUG_WOLFSSH. Sorry.
Perhaps I should configure in the debug code for wolfssh and wolfssl by default so the extra logging can be enabled whenever it is needed.
Adding more calls to GetErrorString() in ssh.c is probably more helpful.
That is done, but there is only one error code that is returned for any cipher, MAC or key mismatch, so DEBUG_WOLFSSH is still required to figure out which one.
It would be good to have a menu config option to define DEBUG_WOLFSSH.
I think the only penalty for enabling it always is an increase in code size, ssuming the "_impure_ptr" is fixed in some way. I asked Mark if that would be reasonable to enable always.
WolfSSH also supports aes128-ctr and aes128-gcm, but I was warned that the latter is much more expensive in speed and memory, so I excluded it from the configuration for compilation.
I think there is full support for aes128-ctr in wolfssl/wolfcrypt, but the places where it needs to be in wolfssh seem to be mostly missing. I had a go at adding it, but I haven't got it working. It does connect, but auth always fails. I haven't had chance to figure out why yet.
wolfssh/src/internal.c does reference AES128_CTR in a few places, but I'm not sure what actions are required.
I started with WolfSSH 1.1.0 when doing the integration into OVMS. There is a 1.2.0 release out now (on github at wolfSSL/wolfssh), and a 1.3.0 release pending that will include Wolf's integration of my SCP additions back into their code base.
-- Steve _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
On Fri, 27 Apr 2018, Mark Webb-Johnson wrote:
It would be good to have a menu config option to define DEBUG_WOLFSSH.
I think the only penalty for enabling it always is an increase in code size, ssuming the "_impure_ptr" is fixed in some way. I asked Mark if that would be reasonable to enable always.
I guess it depends on how much bigger. Debugging the internals of wolfssh is seemingly a rare occurence? Perhaps a menuconfig option (in Components / OVMS / Developer Options) would make sense?
In my build configuration, the size with debug is 1786672, without 1772400, difference 14272. The use case is not so much debugging the internals of wolfssh, rather diagnosing incompatibilities between clients and the the wolfssh server. Enabling DEBUG_WOLFSSH basically compiles in more log statements, but those don't print unless "log level debug wolfssh" is entered. -- Steve
OK. So long as that is just the overhead, it seems fine. Regards, Mark.
On 27 Apr 2018, at 2:33 PM, Stephen Casner <casner@acm.org> wrote:
On Fri, 27 Apr 2018, Mark Webb-Johnson wrote:
It would be good to have a menu config option to define DEBUG_WOLFSSH.
I think the only penalty for enabling it always is an increase in code size, ssuming the "_impure_ptr" is fixed in some way. I asked Mark if that would be reasonable to enable always.
I guess it depends on how much bigger. Debugging the internals of wolfssh is seemingly a rare occurence? Perhaps a menuconfig option (in Components / OVMS / Developer Options) would make sense?
In my build configuration, the size with debug is 1786672, without 1772400, difference 14272.
The use case is not so much debugging the internals of wolfssh, rather diagnosing incompatibilities between clients and the the wolfssh server. Enabling DEBUG_WOLFSSH basically compiles in more log statements, but those don't print unless "log level debug wolfssh" is entered.
-- Steve _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
On Thu, Apr 26, 2018 at 11:33:46PM -0700, Stephen Casner wrote:
The use case is not so much debugging the internals of wolfssh, rather diagnosing incompatibilities between clients and the the wolfssh server. Enabling DEBUG_WOLFSSH basically compiles in more log statements, but those don't print unless "log level debug wolfssh" is entered.
At least for the specific problem with cipher algorithm choice that at least two people (including me) have encountered, a better solution would be to avoid having to resort to debug mode at all by giving that condition its own unique error code that could be returned to the caller. With the additional reporting you have already added, I guess there'd be a clear message logged somewhere---and maybe reported back to the connecting client? I would still be good to have a working menu config option to define DEBUG_WOLFSSH where it really is necessary to dig deeper.
On Fri, 27 Apr 2018, Robin O'Leary wrote:
On Thu, Apr 26, 2018 at 11:33:46PM -0700, Stephen Casner wrote:
The use case is not so much debugging the internals of wolfssh, rather diagnosing incompatibilities between clients and the the wolfssh server. Enabling DEBUG_WOLFSSH basically compiles in more log statements, but those don't print unless "log level debug wolfssh" is entered.
At least for the specific problem with cipher algorithm choice that at least two people (including me) have encountered, a better solution would be to avoid having to resort to debug mode at all by giving that condition its own unique error code that could be returned to the caller. With the additional reporting you have already added, I guess there'd be a clear message logged somewhere---and maybe reported back to the connecting client?
Clearly what you say here is correct. I was coming to that conclusion myself last evening. The reason I have not pursued this solution is that I'm trying to avoid changes to the wolfssh code, such as extending the list of error codes, that would not be part of their release. But since I have established my credentials with them by providing the SCP code, perhaps I can make this change and issue a pull request for it. Reporting back to the connecting client may not be possible because the algorithms have to be agreed before the channel is open. Unfortunately the client diagnostics don't give the necessary details, either, just "SSH2_MSG_KEXINIT sent" and then the connection closes.
I would still be good to have a working menu config option to define DEBUG_WOLFSSH where it really is necessary to dig deeper.
Agreed. I'll see if I can figure out how to properly avoid the _impure_ptr problem. -- Steve
Robin, welcome :) Am 19.04.2018 um 17:39 schrieb Robin O'Leary:
I would like to record the temperature inside the car, but I couldn't see an appropriate metric (I've stuck it on ms_v_charge_temp for now). Is there a better place for it?
There is ms_v_env_temp for the ambient temperature, but that's normally meant for the outside temperature I think. You can add a metric for that, i.e. ms_v_env_cabintemp / "v.e.cabintemp".
What is the intent of ms_v_env_on? It was previously set true when certain CAN traffic was present and false after a period of inactivity. I now set it to true when the car is in state "ready to drive".
A similar question goes for ms_v_env_awake. I've left this doing the CAN activity detection, which means it changes for minor things like detecting a key-fob.
"awake" = Vehicle/bus awake (switched on) "on" = "Ignition" state (drivable)
What is the process for contributing changes? I am currently doing my local work on the master branch cloned from github.
Normal process is using Github pull requests. You push your commits to you repository, then create a pull request. We check your changes and merge them into the master. You should coordinate your work with Tom Parker ("carrott"), the main developer of the Nissan Leaf adaption. To do so you can also add his repository and send pull requests to him (and vice versa). See Github docs for details, it's simple. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
On Thu, Apr 19, 2018 at 10:59:44PM +0200, Michael Balzer wrote:
Am 19.04.2018 um 17:39 schrieb Robin O'Leary:
I would like to record the temperature inside the car, but I couldn't see an appropriate metric (I've stuck it on ms_v_charge_temp for now). Is there a better place for it?
There is ms_v_env_temp for the ambient temperature, but that's normally meant for the outside temperature I think.
Yes, ms_v_env_temp is already being used for that purpose.
You can add a metric for that, i.e. ms_v_env_cabintemp / "v.e.cabintemp".
That seems simple enough... except adding a new standard metric looks like it would have implications for the protocol in ovms_server_v2.cpp.
What is the intent of ms_v_env_on? It was previously set true when certain CAN traffic was present and false after a period of inactivity. I now set it to true when the car is in state "ready to drive".
A similar question goes for ms_v_env_awake. I've left this doing the CAN activity detection, which means it changes for minor things like detecting a key-fob.
"awake" = Vehicle/bus awake (switched on)
"on" = "Ignition" state (drivable)
OK, that's what I assumed for 'on', but I thought I'd better ask advice given this comment in vehicle_nissanleaf.cpp: // FIXME // detecting that on is stale and therefor should turn off probably shouldn't // be done like this // perhaps there should be a car on-off state tracker and event generator in // the core framework? // perhaps interested code should be able to subscribe to "onChange" and // "onStale" events for each metric?
What is the process for contributing changes? I am currently doing my local work on the master branch cloned from github.
Normal process is using Github pull requests. You push your commits to you repository, then create a pull request. We check your changes and merge them into the master.
OK, I have done that.
You should coordinate your work with Tom Parker ("carrott"), the main developer of the Nissan Leaf adaption. To do so you can also add his repository and send pull requests to him (and vice versa).
Yes, I am also familiar with Tom's work from the mynissanleaf.com forum. I think he has mostly been working with a different model year, so it will be interesting to compare the differences between the two.
Robin, Am 20.04.2018 um 00:22 schrieb Robin O'Leary:
You can add a metric for that, i.e. ms_v_env_cabintemp / "v.e.cabintemp". That seems simple enough... except adding a new standard metric looks like it would have implications for the protocol in ovms_server_v2.cpp.
Only if you want to include the metric in the V2 protocol. Then you need to extend the protocol (messages may grow by new fields) and probably modify the server and clients to also parse and display the new data. There are lots of new metrics in V3 that are not covered by the V2 protocol and probably never will. The V2/MP server is included for compatibility, next level development may focus on V3/MQTT. MQTT isn't fixed to message formats and can transport all metrics.
Normal process is using Github pull requests. You push your commits to you repository, then create a pull request. We check your changes and merge them into the master.
OK, I have done that. Yes, I am also familiar with Tom's work from the mynissanleaf.com forum. I think he has mostly been working with a different model year, so it will be interesting to compare the differences between the two.
Tom, Robins changes are only on the Leaf module, nothing relevant to the framework. Can you have a look? https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/44/fil... Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
You can add a metric for that, i.e. ms_v_env_cabintemp / "v.e.cabintemp".
Done. Added.
On 20 Apr 2018, at 4:59 AM, Michael Balzer <dexter@expeedo.de> wrote:
Robin,
welcome :)
Am 19.04.2018 um 17:39 schrieb Robin O'Leary:
I would like to record the temperature inside the car, but I couldn't see an appropriate metric (I've stuck it on ms_v_charge_temp for now). Is there a better place for it?
There is ms_v_env_temp for the ambient temperature, but that's normally meant for the outside temperature I think.
You can add a metric for that, i.e. ms_v_env_cabintemp / "v.e.cabintemp".
What is the intent of ms_v_env_on? It was previously set true when certain CAN traffic was present and false after a period of inactivity. I now set it to true when the car is in state "ready to drive".
A similar question goes for ms_v_env_awake. I've left this doing the CAN activity detection, which means it changes for minor things like detecting a key-fob.
"awake" = Vehicle/bus awake (switched on)
"on" = "Ignition" state (drivable)
What is the process for contributing changes? I am currently doing my local work on the master branch cloned from github.
Normal process is using Github pull requests. You push your commits to you repository, then create a pull request. We check your changes and merge them into the master.
You should coordinate your work with Tom Parker ("carrott"), the main developer of the Nissan Leaf adaption. To do so you can also add his repository and send pull requests to him (and vice versa).
See Github docs for details, it's simple.
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Robin O'Leary wrote:
+ Connected to OVMS access point using android phone. - Tried to visit 192.168.4.1 in phone's web browser (Firefox 55.0.2); it seemed to connect, but would only display a blank page. Hi Robin,
I've seen this a number of times as well, and it's really annoying. It appears that the problem is that the phone is confused about where to send traffic when it has both a WiFi connection to the module, and an LTE connection to the Internet. Simple routing decisions like this were solved decades ago, but it still appears to blow the mind of the little creature within. I think it's so focused on the Internet that it can't believe anything useful would exist elsewhere. Disabling LTE data seems to solve it, but of course, also disables a lot of what you use the "phone" for... That's probably why your Debian system worked. There may also be a notification, usually in the background, when you first connect to the AP that essentially says, "Hey, this AP thing can't connect to the Internet. Do you still want to stay connected to it?" Until you tell it "Yes!", it seems to block all traffic to the AP, leading to timeouts within the browser. My phone is a Google Pixel2, running Android 8.1. As a "best practice", I find that configuring the module to be in AP+Client mode, with a client configuration for your home wifi network (set this up first!) is best. Once your phone and module are both on your home wifi, you can use the phone's web browser to the module's client IP address (instead of 192.168.4.1) to view the same pages as you see when connecting to AP mode, but without the routing hassles. Get the module's IP address from the shell command 'wifi status', or use a Bonjour browser app such as "Bonjour Search HTTP" (free in Google Play from author Tomoaki Takeda) to find it. I leave AP mode on as a fail-safe, in case I need to access the module away from home. It's also used for the Dashboard screen, which is a must-see aid while driving. Greg
On 20/04/18 03:39, Robin O'Leary wrote:
Since then, I got a development environment set up with remarkably little trouble, and I've been adding some new metrics for the Nissan Leaf: * ms_v_bat_soh from 0x5b3[1] * ms_v_charge_temp from 0x54f[0] (this is actually inside temp) * ms_v_door_fl etc. from 0x60d[0] * ms_v_env_gear from 0x421[0] * ms_v_env_handbrake from 0x5c5[0] (was faked by vehicle_nissanleaf_car_on) * ms_v_env_headlights from 0x60d[0,1] * ms_v_env_on from 0x60d[1] (was faked by vehicle_nissanleaf_car_on) ...but continue to fake ms_v_env_awake by CAN activity of 0x284 * ms_v_env_locked from 0x60d[2] * ms_v_inv_temp from 0x510[7] * ms_v_tpms_fl_p etc. from 0x385[2..5] These all seem to be working nicely (at least, on my UK MY2015).
I have a few questions:
I would like to record the temperature inside the car, but I couldn't see an appropriate metric (I've stuck it on ms_v_charge_temp for now). Is there a better place for it?
What is the intent of ms_v_env_on? It was previously set true when certain CAN traffic was present and false after a period of inactivity. I now set it to true when the car is in state "ready to drive".
A similar question goes for ms_v_env_awake. I've left this doing the CAN activity detection, which means it changes for minor things like detecting a key-fob.
I originally wrote this using a 2012 car and the OVMS v2 on the EV can bus, and at the time I didn't know about the VCM status information that is available on the EV bus, so I picked a frame that's only sent when the car is pretty awake, 0x284 is I believe a relayed message from the ABS system. When I learnt about the VCM status information, and also the gear shift status, I didn't bother to update the simple "is the ABS on" logic that I originally used as it works well. The v3 code is an almost verbatim port of v2. I've extended it a little bit here and there but the structure is the same. I'd be pleased to replace these klunky bits and pieces with more direct detection of the car's state.
What is the process for contributing changes? I am currently doing my local work on the master branch cloned from github.
Looking at your pull request I have a couple of comments. We're using Mark's "Whitesmiths" coding style which does take some getting used to. Are coding styles discussed in the developer manual anywhere? Sorry if they're not. Can you add braces to the single line if statements and spacing around operators. (I'm not anymore using an IDE that enforces this style so I sometimes fall back to my normal style). Your comments on 0x5c0 aren't quite right. This /is/ the battery temperature, I've verified that by modifying the value using a man in the middle and watching the battery temperature gauge on the instrument cluster go up and down. It also lines up with the temperatures that you can poll out of the BMS. You changed the flag check from d[0] == 0x40 to (d[0]>>6) == 1, I'm just staring at CAN bus captures and on the car's I've seen, the 0x40 test works but I'm happy to change if there is even a trivial reason to change, do you have any insight into which test is better? I'm already polling the SOH from the BMS with more precision than is available on 0x5b3, but that calculation needs to know the "new car" Ah battery size to convert from the current Ah to the SOH. Can you store the 0x5b3 SOH in a different metric (or a class variable?) to avoid clobbering the existing SOH value. It would be great if you used the 5b3 SOH to discover the correct battery size. Something like the following ought to be true for a 30kWh car and false for a 24kWh(CAC / SOH_5b3 * 100) > 70. That would remove the need to configure the correct Ah to get the SOH calculation to work. The SOC in 0x1db is a fundamentally different value than that which is currently calculated by the OVMS. The 1db value is 100% when fully charged, while what we have now is a percentage of a new car's battery and the value at full charge goes down over time as the battery degrades. My 2012 car shows 73% at full charge, while my 2016 car shows 96%. Can you remove this change from your pull request and we can discuss whether to make it configurable which SOC calculation to use. See Tom Saxton's reply which convincingly dissuaded me wanting to switchto "fully charged is 100%": http://lists.openvehicles.com/pipermail/ovmsdev/2016-May/002993.html (this discussion that was before I knew SOC was available so I had some no longer relevant ideas about how to actually implement it). Did you mean to remove the odometer code? Can you put it back and see if it works with an odometer in miles, I've only been able to test with my km odometers. Thank you for pulling all this new data out of the car CAN bus, I haven't spent much time on that bus since the v2 hardware couldn't talk to it!
Thanks for your comments; I'll just reply to a few quick ones now and come back to the others later. On Fri, Apr 20, 2018 at 11:51:18PM +1200, Tom Parker wrote:
On 20/04/18 03:39, Robin O'Leary wrote:
I would like to record the temperature inside the car, but I couldn't see an appropriate metric (I've stuck it on ms_v_charge_temp for now). Is there a better place for it?
I gather that Mark has already obliged with a new ms_v_env_cabintemp, so I'll move that there.
I'm already polling the SOH from the BMS with more precision than is available on 0x5b3, but that calculation needs to know the "new car" Ah battery size to convert from the current Ah to the SOH. Can you store the 0x5b3 SOH in a different metric (or a class variable?) to avoid clobbering the existing SOH value.
Ah, is that in a separate branch? I didn't see anything in the master repository that set ms_v_bat_soh.
It would be great if you used the 5b3 SOH to discover the correct battery size. Something like the following ought to be true for a 30kWh car and false for a 24kWh(CAC / SOH_5b3 * 100) > 70. That would remove the need to configure the correct Ah to get the SOH calculation to work.
That's an interesting idea! And I guess we will soon have another case to deal with when someone gets a new 40kWh battery.
Did you mean to remove the odometer code? Can you put it back and see if it works with an odometer in miles, I've only been able to test with my km odometers.
I can confirm that the value on the bus is always km regardless of the displayed units preference, which I removed from the ms_v_pos_odometer setting (the git diff got a bit confused, and shows the change as an addition and the deletion separated by a big chunk of new code to do with doors and drive state).
On 21/04/18 04:00, Robin O'Leary wrote:
I'm already polling the SOH from the BMS with more precision than is available on 0x5b3, but that calculation needs to know the "new car" Ah battery size to convert from the current Ah to the SOH. Can you store the 0x5b3 SOH in a different metric (or a class variable?) to avoid clobbering the existing SOH value. Ah, is that in a separate branch? I didn't see anything in the master repository that set ms_v_bat_soh.
It's in master on line 250: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/master...
Did you mean to remove the odometer code? Can you put it back and see if it works with an odometer in miles, I've only been able to test with my km odometers. I can confirm that the value on the bus is always km regardless of the displayed units preference, which I removed from the ms_v_pos_odometer setting (the git diff got a bit confused, and shows the change as an addition and the deletion separated by a big chunk of new code to do with doors and drive state).
Ah, I see now. I'm glad to hear the units are always in km, I copied the approach I took from somewhere, happy leaf I think. If it's not necessary, rip it out. If we discover a car that isn't like this we can deal with it then. Can you remove the 0x355 based unit check and the m_odometer_units variable in the class definition.
On Fri, Apr 20, 2018 at 05:00:59PM +0100, Robin O'Leary wrote:
On Fri, Apr 20, 2018 at 11:51:18PM +1200, Tom Parker wrote:
On 20/04/18 03:39, Robin O'Leary wrote:
I would like to record the temperature inside the car, but I couldn't see an appropriate metric (I've stuck it on ms_v_charge_temp for now). Is there a better place for it?
I gather that Mark has already obliged with a new ms_v_env_cabintemp, so I'll move that there.
I've done that in a new pull request. This avoids changing any existing behaviour (except to remove the fake handbrake setting). It adds: ms_v_door_fl etc. from 0x60d[0] ms_v_env_cabintemp from 0x54f[0] ms_v_env_cooling, ms_v_env_heating from 0x54b[1] ms_v_env_footbrake from 0x292[6] ms_v_env_gear from 0x421[0] ms_v_env_handbrake from 0x5c5[0] (previously faked by vehicle_nissanleaf_car_on) ms_v_env_headlights from 0x60d[0..1] ms_v_env_locked from 0x60d[2] ms_v_env_throttle from 0x180[5] ms_v_inv_temp from 0x510[7] ms_v_tpms_fl_p etc. from 0x385[2..5]
On 27/04/18 01:07, Robin O'Leary wrote:
I've done that in a new pull request.
This avoids changing any existing behaviour (except to remove the fake handbrake setting). It adds:
ms_v_door_fl etc. from 0x60d[0] ms_v_env_cabintemp from 0x54f[0] ms_v_env_cooling, ms_v_env_heating from 0x54b[1] ms_v_env_footbrake from 0x292[6] ms_v_env_gear from 0x421[0] ms_v_env_handbrake from 0x5c5[0] (previously faked by vehicle_nissanleaf_car_on) ms_v_env_headlights from 0x60d[0..1] ms_v_env_locked from 0x60d[2] ms_v_env_throttle from 0x180[5] ms_v_inv_temp from 0x510[7] ms_v_tpms_fl_p etc. from 0x385[2..5]
This looks good Robin. I don't have commit rights, so Michael or Mark will have to merge it. You haven't changed my apparently overly complicated odometer code, does it work correctly with your car? Feel free to clean it up, and also the 0x5c0 mux issue, otherwise I'll do it later next week.
On Fri, Apr 27, 2018 at 10:01:32PM +1200, Tom Parker wrote:
This looks good Robin. I don't have commit rights, so Michael or Mark will have to merge it.
Great, thanks. I'll be interested to know if all the new metrics work equally well on other car model years. I am wondering if we are somehow going to need to keep track of that, either just for documentation, or in the code if behaviour needs to differ.
You haven't changed my apparently overly complicated odometer code, does it work correctly with your car? Feel free to clean it up, and also the 0x5c0 mux issue, otherwise I'll do it later next week.
Yes, both are still on my to-do list; sorry, I've had limited time to go through those and the other things we discussed last week (SOC, SOH, temperature), but hope to catch up this weekend. It's probably best to keep them separate anyway, so it'll be easier to talk about one thing at a time.
On Fri, Apr 27, 2018 at 01:02:48PM +0100, Robin O'Leary wrote:
On Fri, Apr 27, 2018 at 10:01:32PM +1200, Tom Parker wrote:
You haven't changed my apparently overly complicated odometer code, does it work correctly with your car? Feel free to clean it up, and also the 0x5c0 mux issue, otherwise I'll do it later next week.
Yes, both are still on my to-do list; sorry, I've had limited time to go through those and the other things we discussed last week (SOC, SOH, temperature), but hope to catch up this weekend. It's probably best to keep them separate anyway, so it'll be easier to talk about one thing at a time.
I created a new pull request that includes the "ready to drive" detection, fixes ambient temperature conversion, narrows the multiplex check for battery temperature and simplifies the odometer code. It's funny; we now have plenty of temperature readings, but none of them exactly matched the car's display, which said 7°C! v.b.temp 9°C v.c.temp v.e.cabintemp 5.5°C v.e.temp 8°C v.i.temp 8°C v.m.temp
Man with four thermometers never knows how cold it is? Regards, Mark. P.S. I feel for you. It is a balmy (sweaty?) 29 celcius here.
On 2 May 2018, at 10:59 AM, Robin O'Leary <ovmsdev@caederus.org> wrote:
On Fri, Apr 27, 2018 at 01:02:48PM +0100, Robin O'Leary wrote:
On Fri, Apr 27, 2018 at 10:01:32PM +1200, Tom Parker wrote:
You haven't changed my apparently overly complicated odometer code, does it work correctly with your car? Feel free to clean it up, and also the 0x5c0 mux issue, otherwise I'll do it later next week.
Yes, both are still on my to-do list; sorry, I've had limited time to go through those and the other things we discussed last week (SOC, SOH, temperature), but hope to catch up this weekend. It's probably best to keep them separate anyway, so it'll be easier to talk about one thing at a time.
I created a new pull request that includes the "ready to drive" detection, fixes ambient temperature conversion, narrows the multiplex check for battery temperature and simplifies the odometer code.
It's funny; we now have plenty of temperature readings, but none of them exactly matched the car's display, which said 7°C!
v.b.temp 9°C v.c.temp v.e.cabintemp 5.5°C v.e.temp 8°C v.i.temp 8°C v.m.temp _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Hi Mark, Hey, that's a great idea! Actually, I'm in Northern California (in the foothills northeast of Sacramento), where we're actually having a Spring this year. Sometimes it goes from winter to summer in a week. Highs in the mid 70's F (er, that's, um, about 24 C?), lows in the lower 50's (about 10 C), partly cloudy today. Quite pleasant. But give it a month, and we'll be in the upper 90's, pushing 100 down in the valley. Yuck. Greg Mark Webb-Johnson wrote:
Man with four thermometers never knows how cold it is?
Regards, Mark.
P.S. I feel for you. It is a balmy (sweaty?) 29 celcius here.
Am 27.04.2018 um 12:01 schrieb Tom Parker:
This looks good Robin. I don't have commit rights, so Michael or Mark will have to merge it.
Done. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Robin, Could you take a look at the OVMS Metrics Table in Appendix 1 at the end of the user documentation, and let me know what new metrics should be checked as supported by the Leaf? Also, if any are unique or limited to one model vehicle or another, let me know that too. I'll update the table with the new information. User doc is at https://docs.google.com/document/d/16JrXR7rybp-18DrEoeh1rg6GqQT_jVBvhaXh2oEW... Thanks, Greg Michael Balzer wrote:
Am 27.04.2018 um 12:01 schrieb Tom Parker:
This looks good Robin. I don't have commit rights, so Michael or Mark will have to merge it. Done.
Regards, Michael
On Fri, Apr 27, 2018 at 09:58:21AM -0700, Greg D. wrote:
Robin,
Could you take a look at the OVMS Metrics Table in Appendix 1 at the end of the user documentation, and let me know what new metrics should be checked as supported by the Leaf?
User doc is at https://docs.google.com/document/d/16JrXR7rybp-18DrEoeh1rg6GqQT_jVBvhaXh2oEW...
I see you have already added Cabin temperature; here are the other metrics I added (*), and some that were there before my additions but not marked: State of charge [%] v.b.soc State of health [%] v.b.soh Calculated capacity [Ah] v.b.cac Battery temperature [°C] v.b.temp Inverter temperature [°C] v.i.temp (*) Door open flag: Front Left v.d.fl (*) Door open flag: Front Right v.d.fr (*) Door open flag: Rear Left v.d.rl (*) Door open flag: Rear Right v.d.rr (*) Trunk open flag v.d.trunk (*) Gear v.e.gear ms_v_env_gear Drive pedal state [%] v.e.throttle (*) Brake pedal state [%] v.e.footbrake (*) Handbrake Set flag v.e.handbrake (*) Car is Awake flag v.e.awake Car cooling flag v.e.cooling (*) Car heating flag v.e.heating (*) Car HVAC is on flag v.e.hvac Car is On flag v.e.on Car is Locked flag v.e.locked (*) Car headlights are on flag v.e.headlights (*) Ambient temperature [°C] v.e.temp Vehicle odometer [km] v.p.odometer Tire Front Left pressure v.tp.fl.p (*) Tire Front Right pressure v.tp.fr.p (*) Tire Rear Right pressure v.tp.rr.p (*) Tire Rear Left pressure v.tp.rl.p (*)
Also, if any are unique or limited to one model vehicle or another, let me know that too. I'll update the table with the new information.
Currently, I'm not aware of any model-specific metrics, but hopefully we will get feedback from others if there are any.
Tom, Robin, Can you have a look here: https://www.openvehicles.com/node/209 I tried connecting the OVMS 3 unit to my 2016 Leaf. The only thing I got working was the battery SOC (flapping between 133% and 30%) It looks like the unit is sending pre-2016 CAN messages to the car. I have done som extensive logging of my cars CAN-bus and have all the correct data that is needed to get the following to work: Wake CAN Climate control On Climate control Off Start Charging Unlook doors Lock doors Instrument SOC Chargeport open (will be next project) I have implemented theese codes into a geolink unit, and it works by SMS-commands. I would like to see this work on the OVMS V3 as well, but my coding skills are limited. I tried to compile the source code but get this error: /Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_boot.cpp: In constructor 'Boot::Boot()': /Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_boot.cpp:159:46: error: 'xt_set_error_handler_callback' was not declared in this scope xt_set_error_handler_callback(ErrorCallback); If some of you know how to fix it, please let me know. If some of you are interested in the CAN-bus messages, let me know and I can provide it. Thanks, Mark
On 29 Apr 2018, at 2:48 AM, Greg D. <gregd2350@gmail.com> wrote:
Document updated, thanks!
Greg
Robin O'Leary wrote:
On Fri, Apr 27, 2018 at 09:58:21AM -0700, Greg D. wrote:
Robin,
Could you take a look at the OVMS Metrics Table in Appendix 1 at the end of the user documentation, and let me know what new metrics should be checked as supported by the Leaf? User doc is at https://docs.google.com/document/d/16JrXR7rybp-18DrEoeh1rg6GqQT_jVBvhaXh2oEW... <https://docs.google.com/document/d/16JrXR7rybp-18DrEoeh1rg6GqQT_jVBvhaXh2oEWRHw/> I see you have already added Cabin temperature; here are the other metrics I added (*), and some that were there before my additions but not marked:
State of charge [%] v.b.soc State of health [%] v.b.soh Calculated capacity [Ah] v.b.cac Battery temperature [°C] v.b.temp Inverter temperature [°C] v.i.temp (*) Door open flag: Front Left v.d.fl (*) Door open flag: Front Right v.d.fr (*) Door open flag: Rear Left v.d.rl (*) Door open flag: Rear Right v.d.rr (*) Trunk open flag v.d.trunk (*) Gear v.e.gear ms_v_env_gear Drive pedal state [%] v.e.throttle (*) Brake pedal state [%] v.e.footbrake (*) Handbrake Set flag v.e.handbrake (*) Car is Awake flag v.e.awake Car cooling flag v.e.cooling (*) Car heating flag v.e.heating (*) Car HVAC is on flag v.e.hvac Car is On flag v.e.on Car is Locked flag v.e.locked (*) Car headlights are on flag v.e.headlights (*) Ambient temperature [°C] v.e.temp Vehicle odometer [km] v.p.odometer Tire Front Left pressure v.tp.fl.p (*) Tire Front Right pressure v.tp.fr.p (*) Tire Rear Right pressure v.tp.rr.p (*) Tire Rear Left pressure v.tp.rl.p (*)
Also, if any are unique or limited to one model vehicle or another, let me know that too. I'll update the table with the new information. Currently, I'm not aware of any model-specific metrics, but hopefully we will get feedback from others if there are any.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
I've replied, copying here for completeness: Hi meiniac, I'm very sorry I haven't updated the Leaf parts of the OVMS manual. 2016 Leafs are supported with some configuration. It looks like you might have a 30kWh battery which, in theory, is also supported but you're probably the first to test it. I have a 2016 24kWh Leaf and everything works for me (almost). Set the configuration option xnl.modelyear to 2016 to enable 2016 compatible remote commands: config set xnl modelyear 2016 However you also have to unplug the TCU if fitted or it will override the OVMS module's messages. In previous model year cars, this hasn't caused any problems but in the 2016 model year they routed the handsfree microphone through the TCU and the microphone stops working when you unplug the TCU. You assistance in this matter is appreciated as I haven't had time to try to override the TCU using the OVMS. Set the configuration option xnl.maxGids to the appropriate maximum gids for a 30kWh Leaf: config set xnl maxGids 356 I have observed the SOC flapping with a v2 module in a 30kWh Leaf but we never got to the bottom of the problem, we found that the module was sending the SOC correctly and the server was not always sending the correct value to the app. It's possible the server doesn't like SOC above 100% and it will go away when you configure the maxGids correctly? The xt_set_error_handler_callback error is because your esp_idf is out of date. You need the latest from https://github.com/openvehicles/esp-idf.git Please join us on the mailing list if you can (I don't know why you would get permission denied).
Suggestion: Can the model year of the car be determined from the VIN? We do that for a few other of the models. Regards, Mark.
On 30 Apr 2018, at 5:54 PM, Tom Parker <tom@carrott.org> wrote:
I've replied, copying here for completeness: Hi meiniac,
I'm very sorry I haven't updated the Leaf parts of the OVMS manual. 2016 Leafs are supported with some configuration. It looks like you might have a 30kWh battery which, in theory, is also supported but you're probably the first to test it. I have a 2016 24kWh Leaf and everything works for me (almost).
Set the configuration option xnl.modelyear to 2016 to enable 2016 compatible remote commands:
config set xnl modelyear 2016
However you also have to unplug the TCU if fitted or it will override the OVMS module's messages. In previous model year cars, this hasn't caused any problems but in the 2016 model year they routed the handsfree microphone through the TCU and the microphone stops working when you unplug the TCU. You assistance in this matter is appreciated as I haven't had time to try to override the TCU using the OVMS.
Set the configuration option xnl.maxGids to the appropriate maximum gids for a 30kWh Leaf:
config set xnl maxGids 356
I have observed the SOC flapping with a v2 module in a 30kWh Leaf but we never got to the bottom of the problem, we found that the module was sending the SOC correctly and the server was not always sending the correct value to the app. It's possible the server doesn't like SOC above 100% and it will go away when you configure the maxGids correctly?
The xt_set_error_handler_callback error is because your esp_idf is out of date. You need the latest from https://github.com/openvehicles/esp-idf.git <https://github.com/openvehicles/esp-idf.git> Please join us on the mailing list if you can (I don't know why you would get permission denied).
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Here is a list of EU-versions of different years, all are my/previous cars, SJNFAAZE0U6046184 2016 SJNFAAZE0U6033068 2015 SJNFAAZE0U6020423 2014 On 2018-05-01 15:59, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Suggestion: Can the model year of the car be determined from the VIN? We do that for a few other of the models.
Regards, Mark.
On 30 Apr 2018, at 5:54 PM, Tom Parker <tom@carrott.org(mailto:tom@carrott.org)> wrote:
I've replied, copying here for completeness:
Hi meiniac,
I'm very sorry I haven't updated the Leaf parts of the OVMS manual. 2016 Leafs are supported with some configuration. It looks like you might have a 30kWh battery which, in theory, is also supported but you're probably the first to test it. I have a 2016 24kWh Leaf and everything works for me (almost).
Set the configuration option xnl.modelyear to 2016 to enable 2016 compatible remote commands:
config set xnl modelyear 2016
However you also have to unplug the TCU if fitted or it will override the OVMS module's messages. In previous model year cars, this hasn't caused any problems but in the 2016 model year they routed the handsfree microphone through the TCU and the microphone stops working when you unplug the TCU. You assistance in this matter is appreciated as I haven't had time to try to override the TCU using the OVMS.
Set the configuration option xnl.maxGids to the appropriate maximum gids for a 30kWh Leaf:
config set xnl maxGids 356
I have observed the SOC flapping with a v2 module in a 30kWh Leaf but we never got to the bottom of the problem, we found that the module was sending the SOC correctly and the server was not always sending the correct value to the app. It's possible the server doesn't like SOC above 100% and it will go away when you configure the maxGids correctly?
The xt_set_error_handler_callback error is because your esp_idf is out of date. You need the latest from https://github.com/openvehicles/esp-idf.git
Please join us on the mailing list if you can (I don't know why you would get permission denied).
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com(mailto:OvmsDev@lists.openvehicles.com) http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Really strange. I guess the Europeans have a different numbering scheme and don’t have model years? Gary had this for US cars (produced in Japan): https://www.mynissanleaf.com/viewtopic.php?t=1473 <https://www.mynissanleaf.com/viewtopic.php?t=1473> VIN JN1AZ0CP5BT000082 was seen, apparently on one of the Test-Drive LEAFs. JN1 = Nissan Vehicle, Produced in Japan AZ0C = model, engine, etc. does not seem to make sense, conflicting with existing models. A = Engine Type, but A is already assigned Z0 = Model: Z-series ... is this the LEAF designation, or perhaps, Unassigned, or Pre-Production? C = Body type is what? P = Safety type: Passive restraints. Maybe no airbags in this particular LEAF? 5 = Checksum digit, for checking VIN validity B = Model Year 2011 (2010 ... is A, B, ...) T = Manufacturing Plant: Tochigi or Oppama (both Japan) 000082 = Serial number, normally in "completed" order. Wikipedia says <https://en.wikipedia.org/wiki/Vehicle_identification_number> "One consistent element of the VIS is the 10th digit, which is required worldwide to encode the model year of the vehicle. Besides the three letters that are not allowed in the VIN itself (I, O and Q), the letters U and Z and the digit 0 are not used for the model year code. The year code is the model year for the vehicle.”, but that is obviously wrong for the VINs you show. So, maybe only possible on US cars… Seems strange. I wonder how the dealers know which model year. Regards, Mark.
On 1 May 2018, at 11:20 PM, ovms <ovms@topphemmelig.no> wrote:
Here is a list of EU-versions of different years, all are my/previous cars,
SJNFAAZE0U6046184 2016 SJNFAAZE0U6033068 2015 SJNFAAZE0U6020423 2014
On 2018-05-01 15:59, Mark Webb-Johnson <mark@webb-johnson.net> wrote: Suggestion: Can the model year of the car be determined from the VIN? We do that for a few other of the models.
Regards, Mark.
On 30 Apr 2018, at 5:54 PM, Tom Parker <tom@carrott.org <mailto:tom@carrott.org>> wrote:
I've replied, copying here for completeness:
Hi meiniac,
I'm very sorry I haven't updated the Leaf parts of the OVMS manual. 2016 Leafs are supported with some configuration. It looks like you might have a 30kWh battery which, in theory, is also supported but you're probably the first to test it. I have a 2016 24kWh Leaf and everything works for me (almost).
Set the configuration option xnl.modelyear to 2016 to enable 2016 compatible remote commands:
config set xnl modelyear 2016
However you also have to unplug the TCU if fitted or it will override the OVMS module's messages. In previous model year cars, this hasn't caused any problems but in the 2016 model year they routed the handsfree microphone through the TCU and the microphone stops working when you unplug the TCU. You assistance in this matter is appreciated as I haven't had time to try to override the TCU using the OVMS.
Set the configuration option xnl.maxGids to the appropriate maximum gids for a 30kWh Leaf:
config set xnl maxGids 356
I have observed the SOC flapping with a v2 module in a 30kWh Leaf but we never got to the bottom of the problem, we found that the module was sending the SOC correctly and the server was not always sending the correct value to the app. It's possible the server doesn't like SOC above 100% and it will go away when you configure the maxGids correctly?
The xt_set_error_handler_callback error is because your esp_idf is out of date. You need the latest from https://github.com/openvehicles/esp-idf.git <https://github.com/openvehicles/esp-idf.git> Please join us on the mailing list if you can (I don't know why you would get permission denied).
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
On Tue, May 01, 2018 at 09:59:04PM +0800, Mark Webb-Johnson wrote:
Suggestion: Can the model year of the car be determined from the VIN? We do that for a few other of the models.
So in order to read the Leaf VIN and battery data, I had some fun getting to know the ins and outs of ISO-TP and UDS so I could write my own packet reassembler. Of course, it was only when I had it all working nicely that it dawned on me that Mark's comment above meant that there was probably already code for that somewhere that would have saved me the effort, which there is, in OvmsVehicle::PollerReceive and IncomingPollReply. Duh! But when I swapped over to using those methods, I got different results---the first byte of the VIN was missing, and IncomingPollReply never got called with ml_remain==0 for the much longer battery data. So now I was glad that I had my own version for comparison, as it made me more sure than I might otherwise have been that PollerReceive was processing the first frame incorrectly. Indeed, I think it is doing two things wrong: it starts reading data from byte 5 not byte 4, and it gets the overall length wrong by 2 (this confusion is likely because the length given in the ISO-TP layer includes the two UDS header bytes, but the rest of the UDS processing expects those bytes not to be counted in the data passed to IncomingPollReply). Fixing both of those made both the Leaf VIN and battery data come out correctly. My changes are here: https://github.com/caederus-ovms/Open-Vehicle-Monitoring-System-3/tree/leaf-... That leads me to wonder how existing uses of this code haven't run in to the same problems. It is used in at least two places that seem like they should have been affected: OvmsVehicleOBDII::IncomingPollReply case 0x02: // VIN (multi-line response) OvmsVehicleKiaSoulEv::IncomingVMCU case 0x02: // VIN (multi-line response): So could it be that the PollerReceive code is correct after all and that I am misunderstanding how it works, maybe because there is something odd about the Leaf? Could any developers knowledgable about the OBDII interface and the Kia Soul see if my changes make things better or worse? Thanks. btw, I still don't know the answer to the original question of whether the model year of the car can be determined from the VIN, but at least we can now easily see what it is!
I seem to remember that the leaf has a module that bridges the two CAN buses. The issue was that if you poll on the wrong bus when the car is asleep, it wakes up the car 12V (clicking relay), does the poll, then goes back to sleep (clicking relay). Better to use passively transmitted traffic. Perhaps a flag is set to ignore incoming messages until the buses are identified, then when the trigger can message is seen, the arrangement of buses can be determined and the flag cleared. Regards, Mark.
On 6 May 2018, at 10:12 AM, Greg D. <gregd2350@gmail.com> wrote:
Hi Robin,
I'm guessing that the VIN might only be accessible on one of the two CAN interfaces. Would that be sufficient to determine which bus is which?
Greg
Robin O'Leary wrote:
On Tue, May 01, 2018 at 09:59:04PM +0800, Mark Webb-Johnson wrote:
Suggestion: Can the model year of the car be determined from the VIN? We do that for a few other of the models. So in order to read the Leaf VIN and battery data, I had some fun getting to know the ins and outs of ISO-TP and UDS so I could write my own packet reassembler. Of course, it was only when I had it all working nicely that it dawned on me that Mark's comment above meant that there was probably already code for that somewhere that would have saved me the effort, which there is, in OvmsVehicle::PollerReceive and IncomingPollReply. Duh!
But when I swapped over to using those methods, I got different results---the first byte of the VIN was missing, and IncomingPollReply never got called with ml_remain==0 for the much longer battery data. So now I was glad that I had my own version for comparison, as it made me more sure than I might otherwise have been that PollerReceive was processing the first frame incorrectly. Indeed, I think it is doing two things wrong: it starts reading data from byte 5 not byte 4, and it gets the overall length wrong by 2 (this confusion is likely because the length given in the ISO-TP layer includes the two UDS header bytes, but the rest of the UDS processing expects those bytes not to be counted in the data passed to IncomingPollReply). Fixing both of those made both the Leaf VIN and battery data come out correctly. My changes are here:
https://github.com/caederus-ovms/Open-Vehicle-Monitoring-System-3/tree/leaf-... <https://github.com/caederus-ovms/Open-Vehicle-Monitoring-System-3/tree/leaf-poll>
That leads me to wonder how existing uses of this code haven't run in to the same problems. It is used in at least two places that seem like they should have been affected:
OvmsVehicleOBDII::IncomingPollReply case 0x02: // VIN (multi-line response)
OvmsVehicleKiaSoulEv::IncomingVMCU case 0x02: // VIN (multi-line response):
So could it be that the PollerReceive code is correct after all and that I am misunderstanding how it works, maybe because there is something odd about the Leaf? Could any developers knowledgable about the OBDII interface and the Kia Soul see if my changes make things better or worse? Thanks.
btw, I still don't know the answer to the original question of whether the model year of the car can be determined from the VIN, but at least we can now easily see what it is!
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Robin, I don’t think many (any?) are using the OBDII code in the real world. It was there mainly as a proof-of-concept, and looks like that part was broken in the polling port from v2 to v3. VIN not coming up correctly (at all) on my ODBII simulator hardware with vehicle module O2. Not sure about KiaSoulEV. I applied your patch, and the vehicle module O2 vs simulator hardware now identifies the VIN correctly. I can’t really apply your whole commit to the master, as it includes other changes (to vehicle_nissanleaf) which is causing conflicts vs @carrott's recent pull request on Nissan Leaf. In general, easier to keep these code code change commits limited to just one commit (for which a pull request can easily be sent): https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/110 vs https://github.com/caederus-ovms/Open-Vehicle-Monitoring-System-3/commit/06e... Anyway, I manually included the fix to vehicle.cpp and committed that to master - you should be able to pull that back into your now. Can you and @carrott work out what is required and re-do the pull request to include both Nissan Leaf changes? Thanks, Mark.
On 6 May 2018, at 8:56 AM, Robin O'Leary <ovmsdev@caederus.org> wrote:
On Tue, May 01, 2018 at 09:59:04PM +0800, Mark Webb-Johnson wrote:
Suggestion: Can the model year of the car be determined from the VIN? We do that for a few other of the models.
So in order to read the Leaf VIN and battery data, I had some fun getting to know the ins and outs of ISO-TP and UDS so I could write my own packet reassembler. Of course, it was only when I had it all working nicely that it dawned on me that Mark's comment above meant that there was probably already code for that somewhere that would have saved me the effort, which there is, in OvmsVehicle::PollerReceive and IncomingPollReply. Duh!
But when I swapped over to using those methods, I got different results---the first byte of the VIN was missing, and IncomingPollReply never got called with ml_remain==0 for the much longer battery data. So now I was glad that I had my own version for comparison, as it made me more sure than I might otherwise have been that PollerReceive was processing the first frame incorrectly. Indeed, I think it is doing two things wrong: it starts reading data from byte 5 not byte 4, and it gets the overall length wrong by 2 (this confusion is likely because the length given in the ISO-TP layer includes the two UDS header bytes, but the rest of the UDS processing expects those bytes not to be counted in the data passed to IncomingPollReply). Fixing both of those made both the Leaf VIN and battery data come out correctly. My changes are here:
https://github.com/caederus-ovms/Open-Vehicle-Monitoring-System-3/tree/leaf-...
That leads me to wonder how existing uses of this code haven't run in to the same problems. It is used in at least two places that seem like they should have been affected:
OvmsVehicleOBDII::IncomingPollReply case 0x02: // VIN (multi-line response)
OvmsVehicleKiaSoulEv::IncomingVMCU case 0x02: // VIN (multi-line response):
So could it be that the PollerReceive code is correct after all and that I am misunderstanding how it works, maybe because there is something odd about the Leaf? Could any developers knowledgable about the OBDII interface and the Kia Soul see if my changes make things better or worse? Thanks.
btw, I still don't know the answer to the original question of whether the model year of the car can be determined from the VIN, but at least we can now easily see what it is! _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
On Sun, May 06, 2018 at 11:11:32AM +0800, Mark Webb-Johnson wrote:
I applied your patch, and the vehicle module O2 vs simulator hardware now identifies the VIN correctly.
Great!
I can’t really apply your whole commit to the master, as it includes other changes (to vehicle_nissanleaf) which is causing conflicts vs @carrott's recent pull request on Nissan Leaf. In general, easier to keep these code code change commits limited to just one commit (for which a pull request can easily be sent):
Yes, sorry - I felt I needed a sanity check on the PollerReceive stuff before making radical changes to the Leaf structure, but it would have made better sense to have them in separate commits. Thanks for picking it apart anyway! I have updated my branch to merge your commit, but it still needs more polish, if only to take out excessive debug.
On 06/05/18 21:14, Robin O'Leary wrote:
Yes, sorry - I felt I needed a sanity check on the PollerReceive stuff before making radical changes to the Leaf structure, but it would have made better sense to have them in separate commits.
I'm glad you've replaced my single purpose poller state machine with the more general PID poller. I was pretty sure that was possible but never spent the time to work out how to translate how the Leaf works into something the poller could do. Looking at the current state of your branch, you want to store hx in the m_hx metric instead of using the standard SOH metric for both hx and SOC. You can also delete the now unused PollState enum and nl_poll_state variable.
On Tue, May 08, 2018 at 12:13:52AM +1200, Tom Parker wrote:
I'm glad you've replaced my single purpose poller state machine with the more general PID poller. I was pretty sure that was possible but never spent the time to work out how to translate how the Leaf works into something the poller could do.
Yes, it's going to be much easier to add new polls now, though I don't have any definite plans in that direction right now. Maybe the detailed battery cell information might be interesting. Any other suggestions?
Looking at the current state of your branch, you want to store hx in the m_hx metric instead of using the standard SOH metric for both hx and SOC.
Ah, yes, that was a temporary kluge while I was trying to work out how to pass a member function as callback to parent OvmsVehicle class (which meant I wouldn't be able to access m_hx). I ended up keeping all the code together in OvmsVehicleNissanLeaf::IncomingPollReply for now.
You can also delete the now unused PollState enum and nl_poll_state variable.
Done. I think this is ready to merge.
Robin, just a note: I've used this neat ISO-TP implementation for my Arduino projects: https://github.com/altelch/iso-tp …specifically for https://github.com/dexterbg/Twizy-Cfg to provide the OBD2 commands. The OVMS OBD polling framework is currently really just meant to provide periodical polling of basic registers. I will need a more flexible and complete ISO-TP implementation for issue #95 as well, was thinking about a general service for this like I did with CANopen. The Twizy has no standard OBD2 registers and does not follow the standard OBD2 addressing scheme, but of course also provides DTCs and device access via ISO-TP if you know the device addresses. The polling framework is necessary for the Renault Zoe implementation as well, and Wolfgang (Zoe developer) also had some troubles with it. So if you'd like to implement a better ISO-TP framework, go ahead :) As with CAN, a generalized OBD2 service could later also be configured with just a registers to metrics mapping scheme to provide a basic vehicle adaptation without needing to code anything. Regards, Michael Am 06.05.2018 um 02:56 schrieb Robin O'Leary:
On Tue, May 01, 2018 at 09:59:04PM +0800, Mark Webb-Johnson wrote:
Suggestion: Can the model year of the car be determined from the VIN? We do that for a few other of the models. So in order to read the Leaf VIN and battery data, I had some fun getting to know the ins and outs of ISO-TP and UDS so I could write my own packet reassembler. Of course, it was only when I had it all working nicely that it dawned on me that Mark's comment above meant that there was probably already code for that somewhere that would have saved me the effort, which there is, in OvmsVehicle::PollerReceive and IncomingPollReply. Duh!
But when I swapped over to using those methods, I got different results---the first byte of the VIN was missing, and IncomingPollReply never got called with ml_remain==0 for the much longer battery data. So now I was glad that I had my own version for comparison, as it made me more sure than I might otherwise have been that PollerReceive was processing the first frame incorrectly. Indeed, I think it is doing two things wrong: it starts reading data from byte 5 not byte 4, and it gets the overall length wrong by 2 (this confusion is likely because the length given in the ISO-TP layer includes the two UDS header bytes, but the rest of the UDS processing expects those bytes not to be counted in the data passed to IncomingPollReply). Fixing both of those made both the Leaf VIN and battery data come out correctly. My changes are here:
https://github.com/caederus-ovms/Open-Vehicle-Monitoring-System-3/tree/leaf-...
That leads me to wonder how existing uses of this code haven't run in to the same problems. It is used in at least two places that seem like they should have been affected:
OvmsVehicleOBDII::IncomingPollReply case 0x02: // VIN (multi-line response)
OvmsVehicleKiaSoulEv::IncomingVMCU case 0x02: // VIN (multi-line response):
So could it be that the PollerReceive code is correct after all and that I am misunderstanding how it works, maybe because there is something odd about the Leaf? Could any developers knowledgable about the OBDII interface and the Kia Soul see if my changes make things better or worse? Thanks.
btw, I still don't know the answer to the original question of whether the model year of the car can be determined from the VIN, but at least we can now easily see what it is!
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
I am in favour of a separate service, working in co-operation with vehicle.{h, cpp} and retools.{h, cpp}. Something with command-line syntax as well, for requesting individual PIDs, etc, would be extremely useful. Regards, Mark.
On 6 May 2018, at 4:02 PM, Michael Balzer <dexter@expeedo.de> wrote:
Robin,
just a note: I've used this neat ISO-TP implementation for my Arduino projects: https://github.com/altelch/iso-tp <https://github.com/altelch/iso-tp>
…specifically for https://github.com/dexterbg/Twizy-Cfg <https://github.com/dexterbg/Twizy-Cfg> to provide the OBD2 commands.
The OVMS OBD polling framework is currently really just meant to provide periodical polling of basic registers. I will need a more flexible and complete ISO-TP implementation for issue #95 as well, was thinking about a general service for this like I did with CANopen.
The Twizy has no standard OBD2 registers and does not follow the standard OBD2 addressing scheme, but of course also provides DTCs and device access via ISO-TP if you know the device addresses.
The polling framework is necessary for the Renault Zoe implementation as well, and Wolfgang (Zoe developer) also had some troubles with it. So if you'd like to implement a better ISO-TP framework, go ahead :)
As with CAN, a generalized OBD2 service could later also be configured with just a registers to metrics mapping scheme to provide a basic vehicle adaptation without needing to code anything.
Regards, Michael
Am 06.05.2018 um 02:56 schrieb Robin O'Leary:
On Tue, May 01, 2018 at 09:59:04PM +0800, Mark Webb-Johnson wrote:
Suggestion: Can the model year of the car be determined from the VIN? We do that for a few other of the models. So in order to read the Leaf VIN and battery data, I had some fun getting to know the ins and outs of ISO-TP and UDS so I could write my own packet reassembler. Of course, it was only when I had it all working nicely that it dawned on me that Mark's comment above meant that there was probably already code for that somewhere that would have saved me the effort, which there is, in OvmsVehicle::PollerReceive and IncomingPollReply. Duh!
But when I swapped over to using those methods, I got different results---the first byte of the VIN was missing, and IncomingPollReply never got called with ml_remain==0 for the much longer battery data. So now I was glad that I had my own version for comparison, as it made me more sure than I might otherwise have been that PollerReceive was processing the first frame incorrectly. Indeed, I think it is doing two things wrong: it starts reading data from byte 5 not byte 4, and it gets the overall length wrong by 2 (this confusion is likely because the length given in the ISO-TP layer includes the two UDS header bytes, but the rest of the UDS processing expects those bytes not to be counted in the data passed to IncomingPollReply). Fixing both of those made both the Leaf VIN and battery data come out correctly. My changes are here:
https://github.com/caederus-ovms/Open-Vehicle-Monitoring-System-3/tree/leaf-... <https://github.com/caederus-ovms/Open-Vehicle-Monitoring-System-3/tree/leaf-poll>
That leads me to wonder how existing uses of this code haven't run in to the same problems. It is used in at least two places that seem like they should have been affected:
OvmsVehicleOBDII::IncomingPollReply case 0x02: // VIN (multi-line response)
OvmsVehicleKiaSoulEv::IncomingVMCU case 0x02: // VIN (multi-line response):
So could it be that the PollerReceive code is correct after all and that I am misunderstanding how it works, maybe because there is something odd about the Leaf? Could any developers knowledgable about the OBDII interface and the Kia Soul see if my changes make things better or worse? Thanks.
btw, I still don't know the answer to the original question of whether the model year of the car can be determined from the VIN, but at least we can now easily see what it is!
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
On Sun, May 06, 2018 at 10:02:58AM +0200, Michael Balzer wrote:
just a note: I've used this neat ISO-TP implementation for my Arduino projects: https://github.com/altelch/iso-tp
…specifically for https://github.com/dexterbg/Twizy-Cfg to provide the OBD2 commands.
The OVMS OBD polling framework is currently really just meant to provide periodical polling of basic registers. I will need a more flexible and complete ISO-TP implementation for issue #95 as well, was thinking about a general service for this like I did with CANopen.
Yes, I suspect that much of the confusion about data bytes and lengths in PollerReceive would have be avoided if there was a lower level class handling the fiddly bits of ISO-TP. And it would be great to have that available separately for other purposes---I wouldn't then have to use the periodic polling functionality to get something like the VIN, which only needs a one-off query.
... So if you'd like to implement a better ISO-TP framework, go ahead :)
Not sure I am sufficiently up to speed on some of the features needed to do this yet, but I'd be interested in looking at it.
On 28/04/18 04:58, Greg D. wrote:
User doc is at https://docs.google.com/document/d/16JrXR7rybp-18DrEoeh1rg6GqQT_jVBvhaXh2oEW...
Sorry Greg I should have attended to this earlier! In addition to those that Robin has identified we currently have: v.b.voltage v.b.current v.b.range.ideal v.c.voltage (however this is battery side voltage for both AC and DC charging) v.c.current (however this is battery side current for both AC and DC charging) v.c.climit v.c.charging v.c.type v.p.speed v.b.soh v.b.cac I'm not explicitly setting v.type, do we need to in the vehicle code or is that done by the framework? The Leaf also has a couple of specific metrics: m_gids = MyMetrics.InitInt("xnl.v.bat.gids", SM_STALE_HIGH, 0); m_hx = MyMetrics.InitFloat("xnl.v.bat.hx", SM_STALE_HIGH, 0); You can probably just call these gids and hx in your table as this is the common parlance in Leaf circles. Can you also add to the Leaf documentation the following paragraphs: The Leaf support has a number of configuration options: Remote Commands: In model year 2016 Nissan changed how remote commands are handled, switching from the EV bus to the Car bus and changing the messages. The OVMS defaults to pre-2016 behaviour. Set the xnl modelyear configuration option to change to the newer behaviour: config set xnl modelyear 2016 Note that if a CARWINGS, Nissan Connect or the TCU hardware is fitted, the OVMS messages will be overridden by the TCU and when the OVMS tries to wake the car, it will wake up and then go back to sleep. To make remote commands work, the TCU needs to be unplugged if fitted. In model years prior to 2016, this doesn't cause any obvious problems but in the 2016 model year Nissan routed the hands free microphone through the TCU and the microphone stops working when you unplug the TCU. Assistance is appreciated as I haven't had time to try to override the TCU using the OVMS or find an alternative solution to prevent the TCU overriding the messages while still allowing the hands free microphone to work. Battery Size: The OVMS defaults to a 24kWh battery. 30kWh batteries can be accommodated by changing the xnl maxGids configuration option: config set xnl maxGids 356 Range Calculation: The OVMS uses 2 configuration options to calculate remaining range, whPerGid (default 80Wh/gid) and kmPerKWh (default 7.1km/kWh). The range calculation is based on the remaining gids reported by the LBC and at the moment does not hold 5% in reserve like LeafSpy. Feedback on this calculation is welcomed.
About 0x5c0:
You changed the flag check from d[0] == 0x40 to (d[0]>>6) == 1, I'm just staring at CAN bus captures and on the car's I've seen, the 0x40 test works but I'm happy to change if there is even a trivial reason to change, do you have any insight into which test is better?
Well, I think it's always best to make this kind of multiplex index matching as narrow as possible, in case there is something else going on in the adjacent bits that we don't yet know about. I do have a few logs where bits 0--3 have interesting values, but even though I've only ever seen bits 4 and 5 as zero, it doesn't seem wise to assume that when matching the index. It sometimes happens near the end of a charging session (SOC > 90%), when (d[0]>>6)==1 or 2, the values in (d[0] & 0xf) climb independently from 0 to 10 over a period of about a minute, stay at 10 for the rest of the session, then reset back to 0. Full log (37Mb): https://canbus.ro.nu/logs/candump-2016-05-15_112406.log.gz Just the 5c0 packets (103Kb): https://canbus.ro.nu/logs/candump-2016-05-15_112406-5c0.log.gz
On 21/04/18 07:14, Robin O'Leary wrote:
About 0x5c0:
You changed the flag check from d[0] == 0x40 to (d[0]>>6) == 1, I'm just staring at CAN bus captures and on the car's I've seen, the 0x40 test works but I'm happy to change if there is even a trivial reason to change, do you have any insight into which test is better? Well, I think it's always best to make this kind of multiplex index matching as narrow as possible, in case there is something else going on in the adjacent bits that we don't yet know about. I do have a few logs where bits 0--3 have interesting values, but even though I've only ever seen bits 4 and 5 as zero, it doesn't seem wise to assume that when matching the index.
It sometimes happens near the end of a charging session (SOC > 90%), when (d[0]>>6)==1 or 2, the values in (d[0] & 0xf) climb independently from 0 to 10 over a period of about a minute, stay at 10 for the rest of the session, then reset back to 0.
Seeing the other bits being used for something unrelated to the mux is a really good reason to change it! Thank you for noticing this obscure detail in my code!
Great first post. Welcome aboard. Regards, Mark.
On 19 Apr 2018, at 11:39 PM, Robin O'Leary <ovmsdev@caederus.org> wrote:
On Mon, Apr 16, 2018 at 08:59:58PM +0800, Mark Webb-Johnson wrote:
My server is now showing 14 v3.x modules connected (2 of which are mine): ... 1 running 3.1.003-41-gc299c84-dirty/ota_0/ro1
That would be me. As a long-time follower of the project, but first-time user of an actual OVMS device, I would say my "getting started" experience was very good; mostly plusses, with few minuses (and some of those seemed to go away later without my intervention):
+ OVMS unit plugged in to USB power. - No obvious power/status LED (I've since spotted it inside). + Connected to OVMS access point using android phone. - Tried to visit 192.168.4.1 in phone's web browser (Firefox 55.0.2); it seemed to connect, but would only display a blank page. + Connected OK with 'ssh admin@192.168.4.1' + Entered 'enable' and poked around with some wifi/network commands. - Couldn't figure out how to set up wifi client ssid and password. - google docs mentions 'config list wifi.ssid' but not how you add new ones. - Tried 'wifi scan', which cut off my ssh connection. Rebooted.
+ Connected to OVMS access point again, this time with a debian laptop. + Successfully visited 192.168.4.1 in web browser (Firefox 52.3.0). + Changed password as prompted. + Added wifi client ssid and password. - Took a while for me to find the option 'Autostart - Wifi mode:' + Set that to 'Access point + Client'; Save & reboot. + OVMS got an address as a wifi client in my network. + Successfully visited web page on new IP address. - 'ssh admin@NEWIP' connects, but then immediately closes the connection.
+ Plugged module in to car (Nissan Leaf 2016). + Configured vehicle type etc. + Battery, range, odometer, temperature status updates.
+ Configured OVMSv2 server at api.openvehicles.com. + Module's web status says 'State: Connected'. - Not sure how to tell if it's working at the server end. + Download and install android app. - Server defaults to tmc.openvehicles.com (not api....) - Not sure what to put for SMS/module password. - Control - FEATURES, PARAMETERS both get stuck waiting for data. (they started working some time later). + Live values start showing up!
+ Set up account with https://hologram.io/ - google doc doesn't give URL - Tried 'metric list m.net.mdm.iccid', but that just printed 'm.net.mdm.iccid' (it started working some time later). + Activated SIM at https://dashboard.hologram.io/
+ ota update to 3.1.003 worked flawlessly
Since then, I got a development environment set up with remarkably little trouble, and I've been adding some new metrics for the Nissan Leaf: * ms_v_bat_soh from 0x5b3[1] * ms_v_charge_temp from 0x54f[0] (this is actually inside temp) * ms_v_door_fl etc. from 0x60d[0] * ms_v_env_gear from 0x421[0] * ms_v_env_handbrake from 0x5c5[0] (was faked by vehicle_nissanleaf_car_on) * ms_v_env_headlights from 0x60d[0,1] * ms_v_env_on from 0x60d[1] (was faked by vehicle_nissanleaf_car_on) ...but continue to fake ms_v_env_awake by CAN activity of 0x284 * ms_v_env_locked from 0x60d[2] * ms_v_inv_temp from 0x510[7] * ms_v_tpms_fl_p etc. from 0x385[2..5] These all seem to be working nicely (at least, on my UK MY2015).
I have a few questions:
I would like to record the temperature inside the car, but I couldn't see an appropriate metric (I've stuck it on ms_v_charge_temp for now). Is there a better place for it?
What is the intent of ms_v_env_on? It was previously set true when certain CAN traffic was present and false after a period of inactivity. I now set it to true when the car is in state "ready to drive".
A similar question goes for ms_v_env_awake. I've left this doing the CAN activity detection, which means it changes for minor things like detecting a key-fob.
What is the process for contributing changes? I am currently doing my local work on the master branch cloned from github.
Even after upgrading the firmware to the latest from git, I still have the problem with ssh connecting but then immediately dropping. Is there some debug option I should turn on to find out why? _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
participants (7)
-
Greg D. -
Mark Webb-Johnson -
Michael Balzer -
ovms -
Robin O'Leary -
Stephen Casner -
Tom Parker