I have sinned: I have done some patching and upgrading.
NAV 4.2.6 FreeBSD 10.2
Upgraded from gammu-1.33.0_1 to gammu-1.36.8. In this version the python bindings is separated into its own library: py27-gammu-2.4.
Something in the new version makes the dispatcher fail to recognize that the sms is successfully sent:
[2016-01-29 14:25:17,799] [INFO] [pid=83042 nav.smsd] Found 1 unsent message(s) for 12345678. [2016-01-29 14:25:27,287] [WARNING] [pid=83042 nav.smsd.dispatcher] GammuDispatcher failed to send SMS: Returned false. [2016-01-29 14:25:27,288] [INFO] [pid=83042 nav.smsd] Setting delay to 45 seconds.
The sms is indeed sent and the receiver gets 4 identical sms-es.
Any ideas?
--Ingeborg
On Fri, 29 Jan 2016 14:37:04 +0100 Ingeborg Hellemo ingeborg.hellemo@uit.no wrote:
Upgraded from gammu-1.33.0_1 to gammu-1.36.8. In this version the python bindings is separated into its own library: py27-gammu-2.4.
Something in the new version makes the dispatcher fail to recognize that the sms is successfully sent:
[2016-01-29 14:25:17,799] [INFO] [pid=83042 nav.smsd] Found 1 unsent message(s) for 12345678. [2016-01-29 14:25:27,287] [WARNING] [pid=83042 nav.smsd.dispatcher] GammuDispatcher failed to send SMS: Returned false. [2016-01-29 14:25:27,288] [INFO] [pid=83042 nav.smsd] Setting delay to 45 seconds.
The sms is indeed sent and the receiver gets 4 identical sms-es.
Any ideas?
Well, the gammu SendSMS API is expected to return an SMS id integer. If this is not an integer, the GammuDispatcher plugin assumes that the message dispatch failed.
As far as I can grok from the documentation, the latest version of the python bindings still indicate "int" to be the return type of this function. There was a commit in March 2015, however, that changed this into a "long", without updating the corresponding documentation [1].
You could try to change the conditional at [2] to check for "long" instead of "int", to see if that helps. If it does, we can write a patch that will accept both.
[1] https://github.com/gammu/python-gammu/commit/d46a76a012f989c32bffb39baaca535... [2] https://bitbucket.org/mbrekkevold/nav-mirror/src/c8f28932ff910df6931865d8f39...
morten.brekkevold@uninett.no said:
As far as I can grok from the documentation, the latest version of the python bindings still indicate "int" to be the return type of this function. There was a commit in March 2015, however, that changed this into a "long", without updating the corresponding documentation [1].
That would explain the mess! I read the python documentation too and could not understand what had changed.
morten.brekkevold@uninett.no said:
You could try to change the conditional at [2] to check for "long" instead of "int", to see if that helps. If it does, we can write a patch that will accept both.
Changing from "int" to "long" worked nicely. Patch for future versions of NAV would be welcome.
--Ingeborg
On Wed, 3 Feb 2016 11:24:56 +0100 Ingeborg Hellemo ingeborg.hellemo@uit.no wrote:
Changing from "int" to "long" worked nicely. Patch for future versions of NAV would be welcome.
https://bugs.launchpad.net/nav/+bug/1541358