Cannot connect to DeviceHQ when running firmware 5.x
Home › Forums › Conduit: AEP Model › Cannot connect to DeviceHQ when running firmware 5.x
- This topic has 8 replies, 2 voices, and was last updated 5 years, 7 months ago by
Jeff Hatch.
-
AuthorPosts
-
September 9, 2019 at 1:04 am #28608
info@mockingbirdconsulting.co.uk
ParticipantHey all,
I’m hitting an error when trying to configure an AEP Conduit to talk to DeviceHQ. All it does is print “failed to send USR1 to annexcd”.
I’m running firmware version 5.0.0-AEP, however when I log into the box via SSH and run /sbin/monitor-annexcd it refuses to start and just throws the “help” function at me.
Having gone through this and debugged it, I *think* that the issue is a missing –vendor-id flag in the command, however I can’t see from the Web UI what this value might need to be.
Can anyone help with this?
September 9, 2019 at 8:31 am #28613Jeff Hatch
KeymasterBelow is the ps output for the annexcd command line arguments on a Conduit that is successfully checking into devicehq.
root@mtcdt:/var/config/home/admin# ps auxww | grep annexcd
root 4745 0.0 0.6 2704 1540 ? S 13:17 0:00 /bin/bash /sbin/monitor-annexcd
root 4796 0.5 2.6 33068 6784 ? Sl 13:17 0:01 annexcd –account-key XXXXXXXX-xxxx-XXXX-xxxx-XXXXXXXXXXXX –host ds.devicehq.com –port 5798 –product-id MTCDT-LAT3-240L –device-id 12345678 –rpd-interval 43200000 –gps-interval 43200000 –net-interval 43200000 –cell-interval 43200000 –active-apps-interval 43200000 –lora-interval 43200000 –when-ppp-up on –firmware-upgrade true –config-upgrade true –config-upload false –radio-firmware-upgrade true –ssl-method tls –ssl-ca-certificate /etc/ssl/certs/rootCA.pem –ssl-ca-strict –log-upto 7 –dial-on-demand false
root 6163 0.0 0.4 3092 1096 pts/0 S+ 13:21 0:00 grep annexcdThe vendor-id argument is not required in this case. What are the messages from annexcd in /var/log/messages saying?
Jeff
September 9, 2019 at 9:36 am #28614info@mockingbirdconsulting.co.uk
ParticipantThanks.
In the logs, I’m getting
2019-09-09T14:33:38.704293+00:00 mtcdt annexcd: [ERR] main.cc:parse_command_line:382: expected 0 non-options
The full command that I am running is
annexcd –account-key <KEY> –host ds.devicehq.com –port 5798 –product-id MTCDT $ –device-id <DEVID> –rpd-interval 43200000 –gps-interval 43200000 –net-interval 43200000 –cell-interval 43200000 –active-apps-interval 43200000 –lora-interval 43200000 –when-ppp-up on –firmware-upgrade true –config-upgrade true –config-upload false –radio-firmware-upgrade true –ssl-method tls –ssl-ca-certificate /etc/ssl/certs/rootCA.pem –ssl-ca-strict –log-upto 7 –dial-on-demand false-
This reply was modified 5 years, 7 months ago by
info@mockingbirdconsulting.co.uk.
September 9, 2019 at 10:07 am #28616Jeff Hatch
KeymasterDoes the value for the product-id really contain a ‘$’? That is very odd and possibly the problem for parsing the command line arguments by the daemon. I am not sure where that character would be coming from.
At the command line could you perform the following command:
AEP 1.7.x:
mts-id-eeprom –in-file /sys/devices/i2c.3/i2c-0/device/0-0056/eepromAEP 5.x:
mts-id-eeprom –in-file /sys/class/i2c-dev/i2c-0/device/0-0056/eepromThis will show the contents of the eeprom where the product-id and other pertinent information is stored.
Jeff
September 9, 2019 at 10:12 am #28617info@mockingbirdconsulting.co.uk
ParticipantI did think it was weird, but yup, it’s definitely there:
vendor-id: "Multi-Tech Systems" product-id: "MTCDT $" device-id: "DEVID" hw-version: "MTCDT ,0" mac-addr: "00:08:00:00:00:00" imei: "IMEI" capa-gps: true capa-din: false capa-dout: false capa-adc: false capa-wifi: false capa-bluetooth: false capa-lora: false capa: "\x80\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" mac-bluetooth: "00:00:00:00:00:00" mac-wifi: "00:00:00:00:00:00" uuid: "A0800040000000000000000000000021" lora-eui: "00:00:00:00:00:00:00:00" lora-product-id: "" lora-hw-version: ""
That MAC address looks off to me as well…
September 9, 2019 at 10:33 am #28618info@mockingbirdconsulting.co.uk
ParticipantIs it worth my updating to 5.0.1?
September 9, 2019 at 10:44 am #28619Jeff Hatch
KeymasterIs this some kind of sample device? Other than the vendor ID none of the values in the eeprom on that device look valid.
Updating to 5.0.1 without valid values in the EEPROM will not solve this problem.
Setting values in the EEPROM can be done, however, you will need to talk with customer support at support.multitech.com. To write the EEPROM you need to put a jumper on the board and then write the values using a command like the following example:
mts-id-eeprom –in-file /sys/class/i2c-dev/i2c-0/device/0-0056/eeprom –update –out-format bin –uuid
Jeff
September 9, 2019 at 10:46 am #28620info@mockingbirdconsulting.co.uk
ParticipantNope, this has come from one of the UK suppliers and is like this straight out of the box.
Not sure I fancy writing the EEPROM myself, one of the reasons for purchasing MultiTech instead of RAK etc. was that we wouldn’t have to worry about that kind of thing.
I’ll take it up with the supplier, thanks.
September 9, 2019 at 11:02 am #28621Jeff Hatch
KeymasterHmm. You can talk with the supplier, however, it would be a good idea to open a support case with support.multitech.com. Either the supplier did this, or there is an OEM problem of some kind. Whoever/whatever put that ‘$’ in the product-id is what I believe is causing this problem. The support engineers at Multitech can help you fix this, but someone needs to not be messing up the EEPROM values. I don’t think this EEPROM information was what was set in production out of the factory at Multitech.
It may be possible there is/was some kind of problem with the EEPROM. The Multitech support team can help you fix this and should be able to straighten out what is going on with the reseller.
Jeff
-
This reply was modified 5 years, 7 months ago by
-
AuthorPosts
- You must be logged in to reply to this topic.